ИДБ-17-06 Овчинников Кирилл

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

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

Тема ВКР: Разработка и создание модуля “Pick-by-line” для WMS-системы производственного предприятия

Объект исследований: система управления складом

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

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

• А1 Управление предприятием
• А2 Подготовка
• А3 Производство
• А4 Складирование
• А5 Сбыт

Точка зрения: Владелец производственного предприятия

Цель моделирования: определение процессов, которые можно улучшить

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

A-0

A0:

Декомпозиция A1:

Декомпозиция A2:

Декомпозиция A3:

Декомпозиция A4:

Декомпозиция A5:

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

Конфигурация технических средств: сервер, который осуществляет хранение данных; ПК для работы с веб-приложением

Конфигурация программных средств: трехуровневая: клиент - веб-приложение, веб-сервер, сервер БД

Допустимые виды хранилищ и их размещение: объектно-реляционная база данных PostgreSQL

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

Автоматизация процесса A21:

Автоматизация процесса A23:

Автоматизация процесса A24:

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

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

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

• Диаграмма UML Use Case:

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

4.2 Название прецедента: Распределение погрузочных мест

4.3 Контекст: A2 Подготавливать

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

Участник	Категория	Цель (goal)
Пользователь	Внешний	Оформление заказа
Менеджер склада	Основной	Ручной расчет погрузочных мест
WMS-система	Инструмент	Предоставление средств для обработки данных
База данных	Инструмент	Хранение данных о заказах

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

• Условие наличия потока управления: зарегистрированный заказ в БД

• Условие наличия входного потока: состав заказа

• Условие наличия потока исполнителя: параметры расчета погрузочных мест

• Условие наличия потока механизма: CMS-система

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

• Выходной поток: готовый к производству заказ

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

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

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

Условие (риск)	Последствия	Реакция
Недостаток места на складе	Невозможность разместить заказ	Постановка заказа в очередь и уведомление заказчика

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

Участник	Действие (activity)	Ожидаемый результат
Владелец предприятия	Расширение склада	Принятие большего количества заказов

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

• Триггер (событие, стартующее прецедент): Регистрация заказа в БД

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

• Продолжительность прецедента: 30 секунд

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

• Описываемый объект: База данных: Заказы

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

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

• Описываемые процессы и потоки данных: A23 Распределение погрузочных мест

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

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

• Описываемый объект: Структура модуля pick-by-line

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

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

Страница на Github

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

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

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

  Задача: расширение склада для одновременной обработки бóльшего количества заказов.

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

1. Plan (Планирование) :

   1.1 Выявленные проблемы :

   • нехватка места для поступающих заказов;

   • невозможность принять заказы при недостатке места;

   • упущение выгоды.

   1.2 Цель: расширить складское пространство.

   1.3 Требования: расширенный склад должен быть максимально удобным.

   1.4 Ожидаемый результат: увеличенное количество погрузочных мест.

   1.5 Ресурсы, необходимые для достижения ожидаемого результата: строительные материалы на помещение, запчасти для модернизации оборудования, добавление данных о новых погрузочных местах в систему склада

   1.6 Процессы (запланированные действия):

   • Анализ необходимого объема дополнительного пространства

   • Проектирование погрузочных мест

   • Строительство

   • Программная настройка

2. Do (Выполнение) : Рабочие и разработчики выполняют запланированные действия.

3. Check (Проверка) : По завершению производится оценка эффективности и достаточности.

4. Act (Улучшение) : Если после выполненных действий проблемы остались, то необходимо еще раз повторить цикл.

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

  • Каскадная модель разработки;

  • VS Code (с расширениями) в качестве редактора кода;

  • OpenServer для компиляции проекта и тестировании в браузере, phpPgAdmin (дополнение OpenServer) для работы с базой данных

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

• Муда: Ручной расчет мест погрузки заказов
• Мура: Погрузка всех заказов в начале рабочего дня
• Мури: Перегрузка складского пространства

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

Категория	Антипаттерн (риск)	Действие по избежанию
Разработка	Таинственный код (Cryptic code) - использование аббревиатур вместо мнемоничных имён	Давать переменным понятные названия, которые соответствуют их прямому назначению
Архитектура	Раздувание интерфейса (Interface bloat) - разработка интерфейса очень мощным и очень сложным для реализации	Упрощение интерфейса не в ущерб визуальной части
Организация	Раздутый улучшизм (Creeping featurism) - добавление новых улучшений в ущерб суммарному качеству системы	Добавление только тех улучшений, которые имеют максимальное значение
Среда	Синдром варёной лягушки (Boiling Frog Syndrome) — постепенные отрицательные изменения замечают, когда уже поздно	Постоянный мониторинг изменений в сравнении не только с прошлым месяцем, но и прошлыми годами

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

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

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

Способ получения: извлечение из диаграмм IDEF0 и DFD.

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

Менеджер склада тратит:

• Проверка заказа - 2 минуты;
• Расчет погрузочных мест - 8 минут.

Среднее число заказов в день - 100. Следовательно, одному менеджеру нужно иметь рабочую смену в 16,5 часов для обработки всех заказов, когда рабочая смена должна быть 8 часов. Для успешной обработки такого количества заказов потребуется, как минимум, 2 сотрудника.

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

Один сотрудник за смену (8 часов) может обработать ~ 48 заказов.

После внедрения системы автоматического расчета погрузочных мест для заказов, на расчет мест для одного заказа будет тратиться 30 секунд + проверка заказа менеджером - 2 минуты. Итого - 2,5 минуты. Экономия составляет 7,5 минут с одного заказа, или 12 часов в день на одного сотрудника.

С автоматической системой сотрудник сможет обработать за смену ~ 192 заказа, что в 4 раза больше. А при суточном потоке в 100 заказов, с данной работой справится всего один сотрудник.

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

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

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

ВЫВОДЫ

Смотря на значения метода COCOMO II делаем вывод, что система является экономически выгодной (с учетом того, что программисты имеют средние навыки) и может быть реализована за менее чем 5 месяцев командой из 3 человек.

С применением системы экономия времени составит ~ 12 часов в день на отдел менеджеров из 3-х человек при количестве заказов в день равным 100, это позволит иметь в штате меньшее количество сотрудников, тем самым снижая затраты на зарплаты. Также снижается вероятность ошибок, т.к. все расчеты делает система.

Плановое время, затраченное на разработку системы, составляет 4,9 мес, при трудоемкости 2,7 ч/мес. Создание системы: 4,9 мес = 2223 ч/час на разработку.

Так как в день на одного менеджера экономия составляет 12 часов, то в день отдел из 3-х менеджеров экономит 36 часов. Работают менеджеры по 6 дней в неделю. В месяц экономия составляет 864 ч/час. Значит внедрение системы будет иметь точку безубыточности примерно через 3 месяца после даты начала использования.

В результате расчета сложности разработки методом FPA IFPUG было определено 3645 строк кода. На данный момент система разработана на 70% и имеет 2340 строк кода, это означает, что снижение строк кода возможно, но в минимальном количестве. Трудозатраты были снижены за счет упрощения документирования и с использованием предыдущих наработок. Трудоемкость на всю систему составляет 1ч/мес и 5 месяцев. На 70% системы были потрачены 4 месяца с трудоемкостью 1ч/мес или 120ч/час, значит на оставшиеся 30% потребуется 51ч/час, что вполне выполнимо до сдачи ВКР.