Курсовой проект - GorlanovaAV/gorlanovaAV.github.io GitHub Wiki

Курсовой проект по дисциплине "Проектирование информационных систем"

Горланова Анна Вячеславовна, ИДБ-17-05

1. Определение требований к модели ✋

Тема ВКР: Разработка мобильных средств информационной поддержки клиентов автозаправочной станции

Объект исследований: Процессы взаимодействия клиентов с предприятием розничной реализации нефтепродуктов.

Предмет исследований: Средства информационной поддержки клиентов автозаправочной станции.

Процессы верхнего уровня: ✋

  • А1 Авторизироваться в приложении
  • А2 Получить доступ к карте лояльности
  • А3 Получить информацию: "Новости и Акции", "О компани", "О программе лояльности", "FAQ"
  • А4 Узнать стоимость заправки
  • А5 Оставить отзыв

Точка зрения: Пользователь

Цель моделирования: определение автоматизируемых функций информационной поддержки клиентов

2. Функциональное моделирование процессов (IDEF0) ✋

  • A-0 (контекстная диаграмма)

A-0

  • A0 (диаграмма верхнего уровня)

A0

  • A1 (декомпозиция процесса/процессов внутренней среды)

A1

  • A2 (декомпозиция процесса/процессов внутренней среды)

A2

  • A3 (декомпозиция процесса/процессов внутренней среды)

A3

  • A4 (декомпозиция процесса/процессов внутренней среды)

A4

  • A5 (декомпозиция процесса/процессов внутренней среды)

A5

3. Функциональное моделирование программных и информационных средств (DFD) ✋

Конфигурация технических средств: Смартфон, сервер для принятия запросов

Конфигурация программных средств: Рабочая станция

Допустимые виды хранилищ и их размещение: SQLite

  • A12 Автоматизация процесса А12

A12

  • A13 Автоматизация процесса А13

A13

  • A33 Автоматизация процесса А33

A33

  • A43 Автоматизация процесса А43

A43

  • A53 Автоматизация процесса А53

A53

4. Описание выбранного процесса ✋ в формате прецедента (Use Case) ✋

Диаграмма UML Use Case p4

4.1 Идентификатор прецедента: A33

4.2 Название прецедента: Получить нужную информацию

4.3 Контекст: А3 Получить информацию: "Новости и Акции", "О компании", "О программе лояльности", "FAQ"

4.4 Участники (actors) и цели (goals):

Участник Категория Цель (goal)
Пользователь приложения Внутренний Получить интересующую информацию
Мобильное приложение Основной Отобразить пользователю нужную информацию
База Данных Инструмент Сохраняет информацию для пользователей

4.5 Предусловия (pre-conditions):

  • В одноименной с выбранным разделом приложения таблице есть записи с информацией

  • Пользователь приложения авторизирован

4.6 Постусловия (post-conditions):

  • Пользователь получил ответ на свой вопрос, то есть пользователь проинформирован

4.7 Основной поток выполнения (main flow):

Участник Действие (activity) Ожидаемый результат
Мобильное приложение Запрос в Базу Данных Полученная информация по разделу приложения

4.8 Исключения (exceptions):

Условие (риск) Последствия Реакция
Поля запрашиваемой таблицы пусты Пустая страница приложения, без информации Всплывающее уведомление об ошибке

4.9 Альтернативы (alternates):

Участник Действие (activity) Ожидаемый результат
Мобильное приложение Предварительное включение в код статичной информации Появление уведомления "Данные обновляются"

4.10 Временные параметры:

  • Триггер (событие, стартующее прецедент): Пользователь зашел в приложение

  • Номинальная частота повторения прецедента: 200 запросов в сутки

  • Продолжительность прецедента: 2,5 минуты

5. Описание структуры объекта ✋ в формате ERD (Class) ✋

  • Описываемый объект: Мобильное приложение информационной поддержки клиентов АЗС

  • Диаграмма UML Class:

p5

6. Описание алгоритма ✋ в формате UML (Sequence) ✋

  • Описываемые процессы и потоки данных: А33 Получить нужную информацию

  • Диаграмма UML Sequence:

p6

7. Описание состава ✋ в формате UML (Component) ✋

  • Описываемый объект: Структура взаимодействия мобильного приложения с пользователем

  • Диаграмма UML Component:

p7

8. Демонстрация реализации (личная страница)

Демонстрация преподавателю

9. Подготовка к интерпретации построенных моделей

9.1 Используемые паттерны проектирования и разработки ✋:

  • Процессная модель для сравнения:

Задача: Создание мобильного приложения для информационной поддержки клиентов АЗС

Решение задачи при помощи методологии PDCA:

  1. Plan (Планирование): Выявленные проблемы: Недостаточная информированность клиентов АЗС и цифроризация компании

Цели: Повышение уровня клиентоориентрованной стратегии предприятия

Требования:

  • Увеличение заинтересованности клиентов в компании
  • Мобильное приложение должно быть синхронизировано с Базой Данных
  • Ожидаемый результат: Мобильное приложение
  • Ресурсы, необходимые для достижения ожидаемого результата: База Данных, Сервер
  • Процессы (запланированные действия): Проектирование, Создание Базы Данных, Fullstack - разработка системы, Ручное тестирование.

  1. Do (Выполнение): Выполнение поставленных задач сотрудниками, обладающими правами на использование системы.

  2. Check (Проверка): Оценка эффективности на основе результатов внедрения и использования мобильного приложения.

  3. Act (Улучшение): При успешной работе мобильного приложения (при сокращении временных затрат на обработку заказов), он внедряется в информационную систему предприятия, с возможностью доработки или расширения функционала в дальнейшем.

Используемые в разработке паттерны и фреймворки: React

9.2 Используемые паттерны выявления проблем ✋:

  • Муда: Получение информации непосредственно на АЗС
  • Мура: Информирование клиентов оператором осуществляется не равномерно
  • Мури: Отвлечение оператора АЗС лишними вопросами

9.3 Возможные антипаттерны ✋:

Категория Антипаттерн (риск) Действие по избежанию
Разработка Таинственный код - использование аббревиатур вместо понятных имен Соблюдение конвенций разработки
Архитектура Бензиновая фабрика - необязательная сложность дизайна Предварительное проектирование и строгое соблюдение ТЗ
Организация Я тебе это говорил - игнорирование мнения профессионала Привлечение профессионалов
Среда Байкшеддинг - склонность тратить время на обсуждение тривиальных и субъективных вещей Установление жестких временных рамок

10. Интерпретация построенных моделей

10.1 Определение числовых показателей для поставленной цели моделирования:

Цель моделирования - определение автоматизируемых функций информационной поддержки клиентов.

10.2 Определение числовых показателей для цели потенциального проекта автоматизации: ✋

Время и трудозатраты на информирование клиентов и время на поиск пользователем нужной информации

10.3 Расчет потенциального эффекта от автоматизации:

Для ответа на вопросы клиентов работник АЗС тратит 5 минут. При потоке клиентов в 200 человек в сутки 15% из них задают вопросы. В итоге выходит 30 человек в сутки задают вопросы. В сумме на ответы на вопросы у сотрудника уходит: 150 минут (2,5ч) в день. Что в месяц выходит 150 часов или 1800 часов в год.

При внедрении разрабатываемого мобильного приложения процент клиентов, задающих вопросы оператору уменьшится в 10 раз. Получается 3 человека в сутки будут задавать вопрос оператору. В сумме выходит 15 минут (0,4ч) в день сотрудник будет тратить на ответы на вопросы клиентов. Что в месяц выходит 3 часа или 36 часов в год.

**Итого экономия: **

  • 2,5ч - 0,4ч = 2,1ч в смену => 4,2ч экономии в день = 126ч/часов в месяц

10.4 Определение числовых показателей и расчет трудозатрат на разработку программных средств:

Расчет сложности разработки методом FPA IFPUG

Расчет трудозатрат на разработку «с нуля» методом COCOMO II:

10.5 План-факт сравнение для затрат на реализацию: 💻

Исходя из этих расчетов сформируем таблицу

Из расчета:

  • SLOC = 3465 строк кода
  • PM (Трудозатраты) = 10,7 человеко-месяцы
  • TDEV (Полный срок разработки, месяцы) = 7,2 месяцев
  • Эффект от автоматизации (ч/часы в месяц): 126 ч/часов в месяц

Исходя из значений по факту:

  • SLOC = 1248 строк кода
  • PM (Трудозатраты) = 871 человеко-часы
  • TDEV (Полный срок разработки) = 3 месяца
  • Готовность = 80%

ВЫВОДЫ

Исходя из результатов таблицы можно сделать вывод, что за счет внедрения мобильного приложения уменьшаются трудозатраты на информирование пользователей работниками АЗС в 10 раз. Также, за счет сокращения тестирования, документирования кода и использовании CASE-средств удалось сократить срок разработки с 7,2 месяцев до 3. Срок окупаемости разработки сократился в 2 раза с 3,5 месяцев до 1,7 месяца. На данный момент работа выполнена на 80% и на остаток реализации по расчету остался 1 день, что не является критичным.