Курсовой проект - Nan-13/Dmitry- GitHub Wiki

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

Семениченко Дмитрий Владимирович, ИДБ-18-08

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

Тема ВКР: Разработка подсистемы умного помощника ИС УИТП "МГТУ"СТАНКИН"".

Объект исследований:** Процессы подачи и обработки заявок в службе технической поддержки "МГТУ "СТАНКИН"".

Предмет исследований:** АИС технической поддержки МГТУ "СТАНКИН".

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

А1 Обнаружение необходимости услуги (пользователь понимает, что для работы, которую ему нужно выполнять, ему необходимо получить услугу по обслуживанию рабочего места)

А2 Подача заявки

А3 Обработка заявки (работник технической поддержки рассматривает заявку, а дальше либо задаёт уточняющие вопросы пользователю, либо оказывает услугу)

А4 Закрытие заявки ( в АИС обработанная заявка закрывается и в дальнейшем считается, что потребности были удовлетворены)

Точка зрения: Руководитель проекта

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

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

A-0 (контекстная диаграмма)
A0 (диаграмма верхнего уровня)

A1 (декомпозиция блока А1)

А2 (декомпозиция блока А2)

А3 (декомпозиция блока А3)

А4 (декомпозиция блока А4)

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

Конфигурация технических средств: почтовый сервер компании

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

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

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

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

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

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

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

4.2 Название прецедента: Отправка сообщения пользователем в телеграмм

4.3 Контекст: А2

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

Участник	Категория	Цель (goal)
Управление программой	Инструмент	Пользователь выбирает кнопки
telegram бот	Инструмент	Предоставить cредства для автоматизации обращения в техническую поддержку

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

Управление программой
Данные для отправки
telegram bot

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

Пользователь получает услугу

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

Участник	Действие (activity)	Ожидаемый результат
Пользователь	Запускает бота	Заходит в телеграмм бота
Пользователь	Нажимает необходимую кнопку	Выбранная функция бота
Пользователь	Пишет сообщение	В строке вводится информация
Телеграмм бот	Отправляет сообщение	Сообщение отправляется на почту компании
Пользователь	Выходит из телеграмм бота	Завершается работа

Дополнительно при первом запуске:

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

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

Условие (риск)	Последствия	Реакция
Бот не реагирует на кнопки	Пользователь не получает услугу	Обратиться в тех помощь
Бот не регистрирует	Пользователь не получает доступ	Пройти регистрацию еще раз и проверить правильность введенных данных
Бот не отправляет сообщение	Пользователь не может обратиться в тп	Проверить наличие интернета или подождать некоторое время

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

Не предусмотрено

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

Триггер (событие, стартующее прецедент): необходимость в оказании помощи
Номинальная частота повторения прецедента: при появлении необходимости
Продолжительность прецедента: 3 минуты

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

Описываемый объект: Телеграмм бот

Диаграмма ERD Class:

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

Описываемые процессы и потоки данных: А23

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

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

Описываемый объект: Структура программных средств системы

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

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

Имя бота в телеграмм: @Help112ciu_bot

Бот не работает на постоянной основе (03.05.2022), но его можно активировать в любой момент для проверки

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

9.1 Процессная модель "как было" для сравнения ✋:

Процессная модель для сравнения: взаимодействие пользователей с работниками тп происходит в оффлайн режиме или при помощи писем по рабочей почте.

Задача: необходимость автоматизированного процесса подачи заявки на получение услуг тех помощи.

Способ решения: при помощи методологии PDCA (Plan, Do, Check, Act):

PLAN: Задача: Разработать автоматизированного помощника для популярного и удобного мессенджера, телеграмм.

Цель: Сократить время подачи заявки. Добавить процент удобности процесса обращения для пользователя.

Требование: Соблюдение правил нормативных документов, соблюдение законов о работе с информацией пользователей, удобный и простой интерфейс, возможность обратной связи работников ТП с пользователями.

Ожидаемый результат: Улучшение процесса подачи заявки, с помощью сокращения времени обращения, благодаря повышенной доступности системы подачи заявок.

Ресурсы: разработанные требования, сервер для поддержания постоянной работы бота, как минимум два участника взаимодействия.

Процессы: разработка бота на языке программирования С#, разработка функции отправки сообщения от бота на почту ТП, разграничение прав доступа для обычного пользователя и работника ТП, реализовать функции обратной связи между действующими лицами.

DO: Разработать программное обеспечение. (Телеграмм бот)

CHECK: Проверить реализацию выполнения всех необходимых функций.

ACT: Ввести систему в промышленное использование.

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

Муда: Пользователь ищет способ открыть почту.
Мура: Большой поток заявок, который надо в ручном режиме обрабатывать.
Мури: Человеческий фактор, что пользователь может быть загружен на работе и ему не хочется нагружать себя еще больше процессом подачи заявки.

9.3 Используемые для решения наиболее существенных проблем паттерны ✋ и фреймворки ✋, связанные с возможностями автоматизации:

Паттерн: Одиночка (Singleton): который гарантирует, что для определенного класса будет создан только один объект, а также предоставит к этому объекту точку доступа.

Фреймфорк: .NET Framework.

9.4 Возможные антипаттерны в модели "как будет" ✋:

Категория	Антипаттерн (риск)	Действие по избежанию
Разработка	Cryptic code	Комментирование и фиксирование важных частей кода
Архитектура	Magic pushbutton	Перенос функций из обработчика нажатий в отдельную функцию
Организация	Creeping elegance	Использование внутренних стандартов оформления кода
Среда	Buzzword Mania	Использование более приземлённого набора слов

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

10.1 Определение числовых показателей для поставленной цели моделирования: Цель моделирования - определение автоматизированных функций. Автоматизация функций измеряется в функциональных точках, соответственно, числовым показателем для поставленной цели моделирования является количество функциональных точек, которые извлекаются из DFD.

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

Одним из важных числовых показателей являются время и трудозатраты на выполнение процесса.

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

Чтобы пользователю обратиться в службе технической помощи нужно потратить свое время, которое может разниться от способа обращения. Подача заявки по почте может занять от 5 до 10 минут, в зависимости от компьютера или умения пользователя по работе с устройством. Когда нет возможности обратиться по почте, то идет использование внутреннего телефона, которое может затратить от 5 до 10 минут, т.к. нужно найти телефон и номер телефона ТП. Если же нет возможности использовать телефон, то приходится идти пешком до точки работы сотрудников ТП, данный поход может занять абсолютно разное время, зависящее от расстояния до кабинета, от возраста пользователя, от его занятости, что он не может отвлечься от своего места и пойти куда-то.

После внедрения системы обращение будет занимать минуты 3, т.к. телефон всегда под рукой, интернет на телефоне всегда есть, искать ничего не нужно. Взять телефон открыть телеграмм, выбрать диалог с ботом и отправить сообщение.

По итогам расчетов получается эффект автоматизации: 300(заявок)*10(макс предположительное время) = 3000 мин- 300(заявок)*3(мин после автоматизации)=3000-900=2100 минут=2100/60=35ч-ч/мес

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

10.5 План-факт сравнение для затрат на реализацию: 💻

ВЫВОДЫ

Исходя из результатов в таблице 10.5, удалось сократить количество строк кода в 1.1 раза, срок разработки уменьшить до 2.4. Благодаря встроенным библиотекам и использованным фреймворкам удалось немного сократить количество строк кода. Готовность разработки 100 процентов. По итогу различных расчетов, возможно автоматизации по времени не столь существлена, но удобность процессов была повышена.