Курсовой проект - Gorgeouskad/gorgeouskad.github.io GitHub Wiki

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

Кузьмин Антон Дмитриевич, ИДБ-18-05

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

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

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

Предмет исследований: Блок вывода данных

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

  • A1 Поступление заказа на разработку блока вывода данных
  • A2 Разработка технической документации
  • A3 Сборка блока
  • A4 Настройка блока
  • A5 Лабораторные испытания
  • A6 Испытания в составе изделия

Точка зрения: Главный конструктор

Цель моделирования: Обеспечение качества вывода информации системы наведения на основе разработки блока вывода данных.

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

  • A-0 Разработка блока вывода данных для системы наведения специализированного изделия

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

  • A1 Поступление заказа на разработку блока вывода данных:
  1. А11 Ознакомление с техническим заданием

  2. А12 Формирование план-графиков

  3. А13 Передача план-графиков в тематические отделы

  • A2 Разработка технической документации:
  1. А21 Разработка сборочного чертежа изделия
  2. А22 Разработка технических условий изделия
  3. А23 Разработка остальной документации изделия

  • A3 Сборка блока:
  1. А31 Закупка, изготовление компонентов изделия согласно техническим условиям на изделие
  2. А32 Изготовление корпуса изделия согласно сборочному чертежу изделия
  3. А33 Сборка блока согласно сборочному чертежу блока

  • A4 Настройка блока:
  1. А41 Разработка программного обеспечения
  2. А42 Отладка программного кода
  3. А43 Загрузка ПО в блок вывода данных

  • A5 Лабораторные испытания
  1. А51 Производственный контроль
  2. А52 Предъявительские и приемосдаточные испытания

  • A6 Испытания в составе изделия
  1. А61 Старт работы специализированного изделия
  2. А62 Синхронизация и диагностика всех систем изделия
  3. А63 Вывод результатов диагностики изделия
  4. А64 Вывод данных о результатах действия изделия

  • A62 Синхронизация и диагностика всех систем изделия
  1. А621 Начало работы
  2. А622 Диагностика
  3. А623 Результаты

  • A64 Вывод данных о результатах действия изделия
  1. А641 Определение формируемог осигнала
  2. А642 Формирование действия по шаблону сигнала
  3. А643 Ожидание выполнения действия

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

Конфигурация технических средств: Изделие, сигнал.

Конфигурация программных средств: Многоуровневая, распределенная.

Допустимые виды хранилищ и их размещение: Внутренняя память изделия.

  • A52 Предъявительские и приемосдаточные испытания
  1. А521 Собрать рабочее место изделия
  2. А522 Проверить параметры изделия в соответствие с техническими условиями
  3. А523 Составить протоколы о прохождении испытаний блоком

  • A641 Определение формируемого сигнала
  1. А6411 Буфер обмена
  2. А6412 Процессор
  3. А6413 ОЗУ
  4. А6414 Задействованный модуль

  • A643 Ожидание выполнения действия
  1. А6431 Запрашиваемый модуль
  2. А6432 Датчик положения
  3. А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 Процессная модель "как было" для сравнения :

Долгое взаимодействие компонентов системы.

  1. Этап Plan(планирование)
  • Выявление проблемы:

  • Процесс вывода данных без вспомогательных устройств требует больших энергозатрат и времени

  • Цель: уменьшение энергозатрат и ускорение процесса

  • Требования: повысить производительность и эффективность без увеличения трудозатрат

  • Ожидаемый результат: Создан блок вывода данных, уменьшающий энергозатраты и время выполнения задачи

  • Ресурсы, необходимые для достижения ожидаемого результата: Энергоносители, программа

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

    • Разработать технические условия изделия
    • Электрическая схема
    • Программное обеспечение
    • Испытания устройства
  1. Этап Do (Выполнение): Разработчики выполняют поставленные задачи

  2. Этап Check (Проверка): По итогу разработки произвести тестирование. В случае его прохождения, произвести внедрение.

  3. 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%, что удовлетворяет требованиям к разработке полного функционала блока вывода данных системы наведения специализированного изделия.