Skip to content
Notespeak edited this page May 18, 2021 · 38 revisions

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

Смирнов Г.Д., ИДБ-17-07

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

Тема ВКР: Разработка системы управления контроллерами аддитивного оборудования.

Объект исследований: процесс управления и отслеживания операций, направленных на изготовление моделей на контроллерах аддитивных технологий.

Предмет исследований: формализация и автоматизация процесса размещения 3d моделей продукции на линии цеха.

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

  • А0 Управление 3d принтерами в цехе
  • А1 Настройка управляющего сервера
  • А2 Настройка контроллеров 3d принтера
  • А3 Контроль корректности работы системы
  • А4 Оценка эффективности использования разработанной системы

Точка зрения: Руководитель технических систем цеха

Цель моделирования: Моделирование с целью разработки системы управления контроллерами

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

  • Диаграмма А0

none

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

none

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

none

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

none

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

none

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

none

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

Конфигурация технических средств: Jetbrains IDE, ПК с любой операционной системой с поддержкой GUI, MongoDB

Конфигурация программных средств: Многоуровневая Допустимые виды хранилищ и их размещение: БД под управлением MongoDB, файлы формата .stl, .obj, .stp

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

none

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

none

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

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

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 минут

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

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

p6

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

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

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

p7

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

Личная страница на Github

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

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. Интерпретация построенных моделей

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

Стандарт цели: определение процессов требующих повышения качества.

none

Способ получения: извлечение из диаграмм 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 срок кода. В ходе разработки данное число удалось весомо сократить за счет использования готовых библиотек и фреймворков, содержащих в себе подробное описание функционирования большинства использованных функций. Также сокращению затрат на разработку поспособствовало принятие решение об исключение небольшого числа излишних требований к системе, которое не отразилось на её функциональности.