Курсовой проект - GeorgeMelikyan/design.github.io GitHub Wiki
Курсовой проект по дисциплине "Проектирование информационных систем"
Меликян Георгий Витальевич, ИДБ-18-06
1. Определение требований к модели ✋
Тема ВКР: «Разработка алгоритмов автоматизации логистики и управления персоналом сервисного центра»
Объект исследований: логистика и процессы управления персоналом при техническом обслуживании и ремонте смартфонов в сервисном центре.
Предмет исследований: программные и информационные средства автоматизации логистики и управления персоналом
Процессы верхнего уровня: ✋
- А1 — создать новый заказ
- А2 — получить устройство клиента
- А3 — доставить устройство в ближайший сервис
- А4 — выполнить обслуживание
- А5 — вернуть устройство клиенту
Точка зрения: руководитель сервисного центра
Цель моделирования: повышение скорости обслуживания клиентов сервисного центра
2. Функциональное моделирование процессов (IDEF0) ✋
- A-0 Контекстная диаграмма
- A0 Диаграмма верхнего уровня
- A2 Декомпозиция процесса "Получить устройство клиента"
- A3 Декомпозиция процесса "Доставить устройство в ближайший сервис"
- A4 Декомпозиция процесса "Выполнить обслуживание"
- A5 Декомпозиция процесса "Вернуть устройство клиенту"
3. Функциональное моделирование программных и информационных средств (DFD) ✋
Конфигурация технических средств: смартфон, интернет
Конфигурация программных средств: многоуровневая
Допустимые виды хранилищ и их размещение: реляционная БД (MySQL)
A21 Автоматизация процесса "Определение наиболее быстрого свободного курьера"
A31 Автоматизация процесса "Определение ближайшего свободного сервиса"
4. Описание выбранного процесса ✋ в формате прецедента (Use Case) ✋
4.1 Идентификатор прецедента: А4
4.2 Название прецедента: Выполнить обслуживание
4.3 Контекст: А0
4.4 Участники (actors) и цели (goals):
| Участник | Категория | Цель |
|---|---|---|
| Инженер | Основной | Получение информации о заказе, его исполнителях и расчёт скорости доставки |
| Курьер | Основной | Получение информации об адресах доставки для заказа |
| Руководитель | Основной | Получение информации обо всех заказах и исполнителях |
| Система | Инструмент | Предоставление результатов расчёта скорость доставки и выбор исполнителей для заказа |
4.5 Предусловия (pre-conditions):
- Правильно заполнены данные клиента
- Хотя бы один из сети сервисных центров работает и оказывает услуги
- У пользователя есть доступ к Интернету
4.6 Постусловия (post-conditions):
- Выбор наилучших исполнителей для доставки и выполнения заказа
4.7 Основной поток выполнения (main flow):
| Участник | Действие (activity) | Ожидаемый результат |
|---|---|---|
| Инженер | Получает список актуальных заказов | Отображение списка заказов в работе и информация об их исполнителях |
| Курьер | Получает уведомление о назначении на заказ | Отображаются данные заказа |
| Курьер | Запрашивает адрес клиента для получения и выдачи заказа | Получает адрес клиента из заказа |
| Курьер | Заполняет данные о полученном устройстве и вносит результаты визуального осмотра | Данные ВО и устройства попадают в CRM |
4.8 Исключения (exceptions):
| Условие (риск) | Последствия | Реакция |
|---|---|---|
| Нет доступных исполнителей для заказа | Увеличение срока выполнения заказа | Предложение другого времени для обслуживания, компенсация за неудобства |
| Неправильно указан адрес | Увеличение срока выполнения заказа | Уточнение актуального адреса у клиента |
| Задержка курьера в пути | Увеличение срока выполнения заказа | Компенсация за неудобства |
4.9 Альтернативы (alternates):
| Участник | Действие (activity) | Ожидаемый результат |
|---|---|---|
| Пользователь-инженер | Самостоятельный выбор исполнителя для заказа | Исполнитель для заказа выбран вручную |
4.10 Временные параметры:
Триггер (событие, стартующее прецедент): просмотр данных по актуальным заказам курьером или инженером
Номинальная частота повторения прецедента: раз в 10 минут
Продолжительность прецедента: 1 минута
5. Описание структуры объекта ✋ в формате ERD (Class) ✋
-
Описываемый объект: потоки данных
-
Диаграмма UML Class:
6. Описание алгоритма ✋ в формате UML (Sequence) ✋
-
Описываемые процессы и потоки данных: А1
-
Диаграмма UML Sequence:
7. Описание состава ✋ в формате UML (Component) ✋
-
Описываемый объект: Структура программных средств системы
-
Диаграмма UML Component:
8. Демонстрация реализации (личная страница)
9. Подготовка к интерпретации построенных моделей
9.1 Процессная модель "как было" для сравнения ✋:
Способ решения при помощи методологии PDCA:
- Plan (Планирование)
Выявление проблемы:
- Длительное ожидание клиентом доставки
- Увеличенный срок ремонта из-за неправильной нагрузки инженеров
Цель:
- Повышение качества предоставляемого сервиса в сервисном центре
- Увеличение скорости доставки и ремонта
Требования:
- Увеличить скорость обработки заказов посредством оптимизации логистических процессов
- Уменьшить затраты на доставку
- Увеличить количество обрабатываемых заказов
Ожидаемый результат:
- Прирост валовой прибыли сервисного центра за счёт увеличения числа обрабатываемых заказов путём оптимизации логистики.
Ресурсы, необходимые для достижения ожидаемого результата:
- Сервер
- Интернет
- Клиент - смартфон или ПК
Процессы (запланированные действия):
- Проектирование
- Разработка
- Тестирование
- Интеграция
- Поддержка
- Do (Выполнение)
Выполнение запланированных мероприятий.
- Check (Проверка)
Проведение оценки эффективности на основе результатов измерения времени скорости выполнения заказов.
- Act (Корректировка)
При успешном прохождении проверки происходит внедрение с возможностью доработки или расширения функционала в дальнейшем.
9.2 Используемые паттерны выявления проблем в модели "как было" ✋:
Муда: автоматизация решает проблему длительного ожидания доставки. Мура: автоматизация решает проблему распределения курьеров по заказам. Мури: система предупреждает при загруженности курьеров.
9.3 Используемые для решения наиболее существенных проблем паттерны ✋ и фреймворки ✋, связанные с возможностями автоматизации: Не используются.
9.4 Возможные антипаттерны в модели "как будет" ✋:
| Категория | Антипаттерн (риск) | Действие по избежанию |
|---|---|---|
| Разработка | Функции для галочки: Превращение программы в конгломерат плохо реализованных и не связанных между собой функций | Убрать излишний и плохо реализованный функционал |
| Архитектура | Состояние гонки: непредвидение возможности наступления событий в порядке, отличном от ожидаемого | Тестировать все возможные комбинации с точки зрения пользователя с целью предотвращения возможного риска |
| Организация | Аналитический паралич: неоправданно большие затраты на анализ и проектирование | Грамотно составить план финансирования, основываясь на примерах разработки аналогичных систем |
| Среда | Муравейник: под внешней красотой скрывается насаждение целей | Упростить систему |
10. Интерпретация построенных моделей ✋
10.1 Определение числовых показателей для поставленной цели моделирования:
Стандартная цель: определение автоматизируемых функций.
10.2 Определение числовых показателей для цели потенциального проекта автоматизации: ✋
Одним из замечаний по цифровым показателям являются время и трудозатраты на выполнение процесса.
10.3 Расчет потенциального эффекта от автоматизации:
Выполнение одного заказа состоит из 3-х этапов: доставка от клиента в сервис, обслуживание в сервисе, доставка из сервиса клиенту. Один этап доставки занимает в среднем 1 час 45 минут. Среднее время обслуживания — 60 минут. Выбор курьера и расчёт пути занимает 10 минут. Всего на один заказ требуется: 60 минут + 105 минут х 2 + 10 минут = 280 минут.
При введение алгоритма автоматизации логистики выбор курьера и расчёт пути занимает доли секунд, маршрут курьеров будет оптимизирован до среднего времени доставки в 60 минут, а на обслуживание будет выбираться наиболее эффективный исполнитель, за счёт чего время обслуживания сократится до 30 минут. Всего на один заказ требуется: 30 минут + 60 минут х 2 = 160 минут.
Экономия времени составляет 280 - 160 = 120 минут. При средней загрузке сервиса в 6 заказов в день, на всё обслуживание без автоматизации потребуется 1680 минут или 28 часов (заказы выполняются параллельно). При использовании алгоритма автоматизации на обслуживание потребуется всего 960 минут или 16 часов. Это 12 человеко-часов в день.
Сэкономленное время позволит выполнить дополнительный заказ.
10.4 Определение числовых показателей и расчет затрат на реализацию проекта автоматизации:
Расчет сложности разработки методом FPA IFPUG:
Расчет трудозатрат на разработку «с нуля» методом COCOMO II:
10.5 План-факт сравнение для затрат на реализацию: 💻
ВЫВОДЫ
Автоматизация логистического процесса и управления персоналом позволяет увеличить количество заказов на 20 %.
По результатам из п. 10.5 можно сделать вывод, что:
- удалось сократить строки кода в 1,9 раз.
- срок окупаемости разработки сократился в 12,7 раз.
На данный момент работа выполнена на 60%, что позволяет считать, что ВКР будет выполнена в срок. В случае отклонения от графика выполнения работы будут предприняты шаги по уменьшению требований.