Курсовой проект - Gorgeouskad/gorgeouskad.github.io GitHub Wiki
Курсовой проект по дисциплине "Проектирование информационных систем"
Кузьмин Антон Дмитриевич, ИДБ-18-05
1. Определение требований к модели ✋
Тема ВКР: Разработка блока вывода данных для системы наведения специализированного изделия
Объект исследований: Система наведения специализированного изделия
Предмет исследований: Блок вывода данных
Процессы верхнего уровня: ✋
- A1 Поступление заказа на разработку блока вывода данных
- A2 Разработка технической документации
- A3 Сборка блока
- A4 Настройка блока
- A5 Лабораторные испытания
- A6 Испытания в составе изделия
Точка зрения: Главный конструктор
Цель моделирования: Обеспечение качества вывода информации системы наведения на основе разработки блока вывода данных.
2. Функциональное моделирование процессов (IDEF0) ✋
- A-0 Разработка блока вывода данных для системы наведения специализированного изделия
- Декомпозиция блока А0
- A1 Поступление заказа на разработку блока вывода данных:
-
А11 Ознакомление с техническим заданием
-
А12 Формирование план-графиков
-
А13 Передача план-графиков в тематические отделы
- A2 Разработка технической документации:
- А21 Разработка сборочного чертежа изделия
- А22 Разработка технических условий изделия
- А23 Разработка остальной документации изделия
- A3 Сборка блока:
- А31 Закупка, изготовление компонентов изделия согласно техническим условиям на изделие
- А32 Изготовление корпуса изделия согласно сборочному чертежу изделия
- А33 Сборка блока согласно сборочному чертежу блока
- A4 Настройка блока:
- А41 Разработка программного обеспечения
- А42 Отладка программного кода
- А43 Загрузка ПО в блок вывода данных
- A5 Лабораторные испытания
- А51 Производственный контроль
- А52 Предъявительские и приемосдаточные испытания
- A6 Испытания в составе изделия
- А61 Старт работы специализированного изделия
- А62 Синхронизация и диагностика всех систем изделия
- А63 Вывод результатов диагностики изделия
- А64 Вывод данных о результатах действия изделия
- A62 Синхронизация и диагностика всех систем изделия
- А621 Начало работы
- А622 Диагностика
- А623 Результаты
- A64 Вывод данных о результатах действия изделия
- А641 Определение формируемог осигнала
- А642 Формирование действия по шаблону сигнала
- А643 Ожидание выполнения действия
3. Функциональное моделирование программных и информационных средств (DFD) ✋
Конфигурация технических средств: Изделие, сигнал.
Конфигурация программных средств: Многоуровневая, распределенная.
Допустимые виды хранилищ и их размещение: Внутренняя память изделия.
- A52 Предъявительские и приемосдаточные испытания
- А521 Собрать рабочее место изделия
- А522 Проверить параметры изделия в соответствие с техническими условиями
- А523 Составить протоколы о прохождении испытаний блоком
- A641 Определение формируемого сигнала
- А6411 Буфер обмена
- А6412 Процессор
- А6413 ОЗУ
- А6414 Задействованный модуль
- A643 Ожидание выполнения действия
- А6431 Запрашиваемый модуль
- А6432 Датчик положения
- А6433 Подтверждение
4. Описание выбранного процесса ✋ в формате прецедента (Use Case) ✋
Диаграмма UML Use Case
4.1 Идентификатор прецедента: A41
4.2 Название прецедента: Выполнение действия в зависимости от частоты сигнала
4.3 Контекст: A4
4.4 Участники (actors) и цели (goals):
| Участник | Категория | Цель (goal) |
|---|---|---|
| Поступающий сигнал | Внутренний | Поступающий в устройство сигнал для какого либо действия |
| Внутренняя память устройства | Внутренний | Определение шаблона сигнала для выполнения действия |
4.5 Предусловия (pre-conditions):
-
Наличие данных о частоте сигнала
-
Наличие данных о шаблоне действия при определенной частоте сигнала
4.6 Постусловия (post-conditions):
- Совершенное действие, которое зависит от шаблона сигнала
4.7 Основной поток выполнения (main flow):
| Участник | Действие (activity) | Ожидаемый результат |
|---|---|---|
| Внутренняя память устройства | Определение шаблона сигнала | Определенный шаблон сигнала |
| Внутренняя память устройства | Определение шаблона действия | Определенный шаблон действия |
| Внутренняя память устройства | Выполнение действия | Выполненное действие |
4.8 Исключения (exceptions):
| Условие (риск) | Последствия | Реакция |
|---|---|---|
| Определение неопознанного шаблона сигнала | Ошибка системы | Сформированный отчет об ошибки сбоя системы |
4.9 Альтернативы (alternates):
Не предусмотрено
4.10 Временные параметры:
-
Триггер (событие, стартующее прецедент): Выполненное действие
-
Номинальная частота повторения прецедента: В зависимости от времени запроса
-
Продолжительность прецедента: n тактов
5. Описание структуры объекта ✋ в формате ERD (Class) ✋
-
Описываемый объект: Внутренняя память устройства: шаблоны сигналов
-
Диаграмма UML Class:
6. Описание алгоритма ✋ в формате UML (Sequence) ✋
-
Описываемые процессы и потоки данных: A41 Выполнение действия в зависимости от частоты сигнала
-
Диаграмма UML Sequence:
7. Описание состава ✋ в формате UML (Component) ✋
-
Описываемый объект: Структура модуля отправки сигнала
-
Диаграмма UML Component:
8. Демонстрация реализации (личная страница)
- Система наведения специализированного изделия (предположительный вид)
9. Подготовка к интерпретации построенных моделей
9.1 Процессная модель "как было" для сравнения ✋:
Долгое взаимодействие компонентов системы.
- Этап Plan(планирование)
-
Выявление проблемы:
-
Процесс вывода данных без вспомогательных устройств требует больших энергозатрат и времени
-
Цель: уменьшение энергозатрат и ускорение процесса
-
Требования: повысить производительность и эффективность без увеличения трудозатрат
-
Ожидаемый результат: Создан блок вывода данных, уменьшающий энергозатраты и время выполнения задачи
-
Ресурсы, необходимые для достижения ожидаемого результата: Энергоносители, программа
-
Процессы (запланированные действия):
-
- Разработать технические условия изделия
-
- Электрическая схема
-
- Программное обеспечение
-
- Испытания устройства
-
Этап Do (Выполнение): Разработчики выполняют поставленные задачи
-
Этап Check (Проверка): По итогу разработки произвести тестирование. В случае его прохождения, произвести внедрение.
-
Act (Улучшение): Если после разработки проблема возникают проблемы, провести сопровождение.
9.2 Используемые паттерны выявления проблем в модели "как было" ✋:
- Муда: Оформление документации сотрудникам компании
- Мура: Несформированные документы
- Мури: Отвлечение сотрудника от основной работы
9.3 Используемые для решения наиболее существенных проблем паттерны ✋ и фреймворки ✋, связанные с возможностями автоматизации:
9.4 Возможные антипаттерны в модели "как будет" ✋:
| Категория | Антипаттерн (риск) | Действие по избежанию |
|---|---|---|
| Разработка | Жёсткое кодирование (Hard code) - внедрение предположений об окружении программы в большом количестве точек её реализации | При разработке учитывать возможность настраиваемости конфигурации |
| Архитектура | Golden hammer — антипаттерн проектирования, проявляется в использовании одного и того же "решения" везде где только можно, в том числе путём искусственной "подгонки" условий. | При решении задачи продумывать не одно решение, а несколько, определить достоинства и недостатки, и делать взвешенный выбор в пользу самого удачного решения — именно к поиску таких решений и сводится эффективная разработка. |
| Организация | Аналитический паралич. Неоправданно большие затраты на анализ и проектирование. | Не задерживаться на стадии анализа и проектирования |
| Среда | Расползание рамок (Scope creep) - потеря контроля над разрастанием проекта | Определение четкого понимания требований проекта |
10. Интерпретация построенных моделей ✋
10.1 Определение числовых показателей для поставленной цели моделирования:
Цель моделирования: определение автоматизируемых функций.
10.2 Определение числовых показателей для цели потенциального проекта автоматизации: ✋
10.3 Расчет потенциального эффекта от автоматизации:
Расчет потенциального эффекта от автоматизации: Для корректного взаимодействия различных составных приборов изделия, необходимо автоматизировано перенаправлять сигналы между ними. До разработки блока вывода данных, отправка и получение адресатом сигнала могло занимать до 60 секунд времени, что в условиях работы системы наведения специализированного изделия может сказаться на эффективности работы. После разработки блока вывода данных, данная задача была автоматизирована и по времени не превышает 1-3 секунд. Получается если раньше пилоту вручную приходилось передвигать тумблеры, нажимать кнопки для взаимодействия модулей, сейчас достаточно отправить поток данных, нажав одну кнопку.
Если раньше пилот тратил примерно 5 - 7 минут на выполнение операции, а следовательно за время работы могло уходить до 20-30 минут на выполнение конкретного действия, сейчас такая же задача будет выполнена за 2 - 5 минут. Возьмем в среднем выполнение 10 операций при работе изделия и в среднем 5 рабочих дней изделия в месяц. соответственно экономия составит примерно 21 час в месяц.
Соответственно это позволило более быстро и эффективно выполнять задачи, поставленные перед системой наведения специализированного изделия.
10.4 Определение числовых показателей и расчет затрат на реализацию проекта автоматизации:
Расчет сложности разработки методом FPA IFPUG:
Расчет трудозатрат на разработку «с нуля» методом COCOMO II:
10.5 План-факт сравнение для затрат на реализацию: 💻
Исходя из параметров, полученных в пунктах 10.1-10.4, можно составить следующую таблицу трудозатрат:
ВЫВОДЫ
Исходя из результатов анализа трудозатрат, проведенных в пункте 10.5, можно сделать вывод, что за счет повторного использования кода для некоторых функций удалось сократить строки кода (SLOC) в 1,1 раза. Срок разработки сократить не удалось. Срок окупаемости уменьшился в 1,6 раз. На данный момент работа выполнена на 95%, что удовлетворяет требованиям к разработке полного функционала блока вывода данных системы наведения специализированного изделия.