-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Определение требований к модели ✋
Тема ВКР: Разработка системы управления контроллерами аддитивного оборудования.
Объект исследований: процесс управления и отслеживания операций, направленных на изготовление моделей на контроллерах аддитивных технологий.
Предмет исследований: формализация и автоматизация процесса размещения 3d моделей продукции на линии цеха.
Процессы верхнего уровня: ✋
- А0 Управление 3d принтерами в цехе
- А1 Настройка управляющего сервера
- А2 Настройка контроллеров 3d принтера
- А3 Контроль корректности работы системы
- А4 Оценка эффективности использования разработанной системы
Точка зрения: Руководитель технических систем цеха
Цель моделирования: Моделирование с целью разработки системы управления контроллерами
2. Функциональное моделирование процессов (IDEF0) ✋
- Диаграмма А0

- Декомпозиция А0

- Декомпозиция А1

- Декомпозиция А2

- Декомпозиция А3

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

3. Функциональное моделирование программных и информационных средств (DFD) ✋
Конфигурация технических средств: Jetbrains IDE, ПК с любой операционной системой с поддержкой GUI, MongoDB
Конфигурация программных средств: Многоуровневая Допустимые виды хранилищ и их размещение: БД под управлением MongoDB, файлы формата .stl, .obj, .stp
- Автоматизация процесса А31

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

4.1 Идентификатор прецедента: A32
4.2 Название прецедента: Тесты в режиме предприятия
4.3 Контекст: Контроль корректности работы системы
4.4 Участники (actors) и цели (goals):
| Участник | Категория | Цель (goal) |
|---|---|---|
| Команда разработки | Основной | Протестировать готовую систему на базе предприятия |
| Руководитель | Внешний | Предоставление финансовых и физических ресурсов (активов) |
| Приложение | Инструмент | Передать 3d модель на контроллер 3d принтера |
| Приложение | Инструмент | Передать команду контрольного действия (Печать) |
| Приложение | Инструмент | Обработать, сформировать и записать данные в БД |
4.5 Предусловия (pre-conditions):
-
Условие наличия потока управления: Цели и ресурсы предприятия
-
Условие наличия входного потока: Готовая система
-
Условие наличия потока исполнителя: Концепция разрабатываемой системы
-
Условие наличия потока механизма: Конечная работающая система ( успешно пройдены все тесты 4.6 Постусловия (post-conditions):
-
Выходной поток: Корректно функционирующая система
4.7 Основной поток выполнения (main flow):
| Участник | Действие (activity) | Ожидаемый результат |
|---|---|---|
| Оператор | Получает актуальную информацию о состоянии контроллеров и аддитивного оборудования | Получение всех уведомлений системы |
| Оператор | Выполняет управляющие команды на конечном оборудовании | Управление 3d принтерами |
| Приложение | Функционирует | Обрабатывает статистические данные, передает 3d модели, контрольные действии на контроллеры 3d принтера |
| 4.8 Исключения (exceptions): |
| Условие (риск) | Последствия | Реакция |
|---|---|---|
| Ввод некорректных данных | Сбой в работе приложения | Сообщить пользователю о некорректности введенных данных |
| Отправка некорректного файла | Сбой в работе приложения | Сообщить пользователю о проблеме с файлом |
| Сбой в работе или недоступность сервера | Прекращение функицонирования приложения | Сообщить оператору о временных технических неполадках и при наличии интернет соединения отправить администратору сообщение о сбое |
4.9 Альтернативы (alternates):
| Участник | Действие (activity) | Ожидаемый результат |
|---|---|---|
| Администратор | Ручное размещение моделей | Успешный запуск производственной задачи |
4.10 Временные параметры:
-
Триггер: Оператор загружает модель на контроллер аддитивного оборудования
-
Номинальная частота повторения прецедента: 15 в сутки
-
Продолжительность прецедента: 20 минут
-
Описываемый объект: База данных приложения
-
Описываемые процессы и потоки данных: А31

-
Описываемый объект: Компоненты web-приложения оформления заказов на изготовление изделий с применением современных аддитивных технологий
-
Диаграмма UML Component:

Личная страница на Github
9.1 Используемые паттерны проектирования и разработки ✋:
- Процессная модель для сравнения:
Процессная модель для сравнения представляет собой систему, в которой реализовано уменьшение роли оператора и большее взаимодействие самого клиента непосредственно с системой для наиболее эффективной обработки данных
Для реализации подобной системы нет необходимости менять процессную модель (состав и последовательность процессов P-D-C остаются прежними) Задача: Необходимо повысить производительность цеха, работы аддитивного оборудования Решение задачи при помощи методологии PDCA:
1.Этап Plan(Планирование):
1.1 Выявленные проблемы:
- чрезмерные затраты времени на инициализацию производственной задачи (Оператор должен авторизоваться в каждый контроллер для 3d принтера, что не позволяет быстро реагировать на возможные проблемы);
- чрезмерные затраты времени на передачу данных конечному оборудованию;
- долгий простой, до обнаружения ошибки
1.2 Цель: оптимизировать временные затраты на обработку данных;
1.3 Требования: уменьшить время обработки данных без увеличения количества сотрудников.
1.4 Ожидаемый результат: повышение эффективности обработки данных;
1.5 Ресурсы, необходимые для достижения ожидаемого результата: необходима информационная система обработки данных (web-приложение, БД, сервер);
1.6 Процессы (запланированные действия):
- Проектирование
- Создание макета дизайна web-составляющей
- Программная настройка
2.Этап Do (Выполнение):
Сотрудники выполняют поставленные задачи
3.Этап Check (Проверка):
По итогу внедрения разработанного web-приложения производится оценка эффективности
4.Этап Act (Улучшение):
Если запланированные действия начинают выдавать ожидаемый результат (уменьшается время обработки), то приложение принимается за основу и внедряется с последующей доработкой.
- Используемые в разработке паттерны и фреймворки:
В качестве фонтенда был выбран Node.js со стандартным HTML/CSS-фреймворком, который включает в себя также готовые стили и плагины.
9.2 Используемые паттерны выявления проблем ✋:
- Муда: Работники предприятия извлекают и монтируют носители информации.
- Мура: Флеш память изнашивается.
- Мури: Потеря операционных данных и искажению информации (3d моделей), повышение рисков брака.
9.3 Возможные антипаттерны ✋:
| Категория | Антипаттерн (риск) | Действие по избежанию |
|---|---|---|
| Разработка | Спагетти-код — слабо структурированная и плохо спроектированная система, запутанная и очень сложная для понимания. Такой код так же очень часто содержит в себе множество примеров анти-паттерна программирования копи-пастом. Подобный код в будущем не сможет разобрать даже его автор. В ООП спагетти-код может быть представлен в виде небольшого количества объектов с огромными, по размеру кода, методами. | Рефактор спагетти-кода, переписывание функций. |
| Архитектура | Божественный объект (God Object) - такой объект берет на себя слишком много функций и/или хранит в себе практически все данные. В итоге мы имеем непереносимый код, в котором, к тому же, сложно разобраться. Так же, подобный код довольно сложно поддерживать, учитывая, что вся система зависит практически только от него | Разбивать задачи на подзадачи, с возможностью решения этих подзадач различными разработчиками |
| Организация | Scope creep: Неконтролируемо разрастание или “расползание” границ проекта, приводящее к срыву сроков, перерасходу бюджета или снижению качества, чтобы удержаться в границах проекта | Держать под контролем масштабы проекта |
| Среда | Чрезмерное усложнение: Расходы ресурсов, что делает проект более устойчивым и сложным, чем это необходимо | Четко установить задачи и ограничения в ТЗ |
10.1 Определение числовых показателей для поставленной цели моделирования:
Стандарт цели: определение процессов требующих повышения качества.

Способ получения: извлечение из диаграмм IDEF0 и DFD.
10.2 Определение числовых показателей для цели потенциального проекта автоматизации: ✋
Одним из важных числовых показателей является временные затраты оператора на размещение производственной задачи.
10.3 Расчет потенциального эффекта от автоматизации:
Оператор производства, чтобы ввести данные будущего клиента и разместить модель , тратит в среднем 20 минут. Среднее число обращений оператора к контроллеру за рабочий день составляет 15 раз. В целом это действие может занять 5 часов. Подобное распределение рабочего времени нецелесообразно. После внедрения информационной системы на размещение производственной задачи (3d модели и управляющих действий), значительно повысится эффективность и скорость размещения 3d моделей на оборудовании цеха, тем самым разгружая оператора для других задач.
После внедрения информационной системы на размещение одной производственной задачи понадобится 3 минуты, и те же 15 обращений к системе за сутки: (15 * 3) / 60 = 0,75 часов.
Рассмотрим период в 1 месяц: 30 суток и 3 оператора.
Итого экономия времени составит: 5ч-0,75ч=4,25 часов, в месяц 4,25ч * 30 дней = 127,5 часов. При наличии 3 операторов, которые обращаются к системе 9 часов в сутки, ежемесечная экономия времени будет: 127,5 * 3 = 382,5 человеко-часов в месяц.
10.4 Определение числовых показателей и расчет трудозатрат на разработку программных средств:
Расчет сложности разработки методом FPA IFPUG:

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

10.5 План-факт сравнение для затрат на реализацию: (https://docs.google.com/spreadsheets/d/14zHITbhf3L0thqi4B9MFxybmuZqB4eCkjwUlEmXVR4s/edit?usp=sharing)
ВЫВОДЫ
Плановое время, затраченное на разработку системы, составляет 1,2 ч/мес, что равно 115,2 ч/час. Так как экономия времени в день приблизительно 4 часа, можно сделать вывод, что точка безубыточности будет находиться на отметке 2,4 мес. Далее компания будет иметь экономическую прибыль от внедрения системы.
В результате расчета сложности разработки методом FPA IFPUG было определено 2992 срок кода. В ходе разработки данное число удалось весомо сократить за счет использования готовых библиотек и фреймворков, содержащих в себе подробное описание функционирования большинства использованных функций. Также сокращению затрат на разработку поспособствовало принятие решение об исключение небольшого числа излишних требований к системе, которое не отразилось на её функциональности.