Сопровождение подсистемы для автосервиса

ВведениеВ современном мире быстрый и качественный доступ к нужной информации является одним из главных критериев эффективности управления организацией или производством и поэтому современная жизнь немыслима без эффективного управления. Важной категорией являются системы обработки информации, от которых во многом зависит эффективность работы любого предприятия или учреждения. Данная работа посвящена разработке автоматизированной подсистемы автомобильного сервисного центра. Подсистема будет разработана средствами Borland C++Builder 6.0 с использованием клиент – серверной технологии. Клиент-сервер — вычислительная или сетевая архитектура, в которой задания или сетевая нагрузка распределены между поставщиками услуг, называемыми серверами, и заказчиками услуг, называемыми клиентами. Физически клиент и сервер это программное обеспечение. Обычно они взаимодействуют через компьютерную сеть посредством сетевых протоколов и находятся на разных вычислительных машинах, но могут выполняться также и на одной машине. Необходимо разработать функциональные модели будущей подсистемы с помощью CASE средства BPWin, ссылаясь на ранее разработанное техническое задание. Создать программное средство для автоматизации основной деятельности фирмы. А так же разработать инструкцию по эксплуатации для созданной подсистемы. Целью работы является разработка информационной подсистемы для автоматизации, повышения эффективности работы сервисного центра. Для повышения эффективности работы сервисного центра будет создана база данных, содержащая информацию о клиентах, сотрудниках, заказах, товаре. Задачи работы следующие: − провести анализ предметной области; − разработать функциональные модели автоматизированной подсистемы (АП) сервисного центра;− разработать информационную модель АП сервисного центра; − разработать программное обеспечение для АП сервисного центра. В первой части исследуется предметная область и разрабатывается техническое задание. Во второй части рассматривается разработка модели на создаваемую подсистему с использованием методологий IDEF0, IDEF3, DFD. В третьей части описано руководство на использование подсистемы, показан пользовательский интерфейс при работе с win-приложением. Выполняется проверка работоспособности информационной подсистемы. В четвертой части разрабатывается пользовательский интерфейс. 1. Предпроектное обследование предметной области1.1 Системный анализ и анализ требований к информационной системеАвтосервис - это комплекс организационно-технических мероприятий, документов и производств, обеспечивающих реализацию, полезность, работоспособность и сохранность автотранспортных средств (АТС) в соответствии с требованиями их владельцев и общества. Автосервис охватывает наибольший период жизненного цикла АТС от момента выхода машин с завода - изготовителя до их окончательной утилизации, включая последнюю. Под автосервисом понимают поддержание (техническое обслуживание) и восстановление (ремонт) работоспособности АТС преимущественно легковых автомобилей на станциях технического обслуживания (СТО). Вместе с тем сфера оказания услуг потребителям, связанным с эксплуатацией АТС значительно шире. Возрастание роли автосервиса в последние годы объясняется чисто экономическими соображениями. Значительная часть автомобилей и их владельцев участвуют в производственном процессе, в котором каждый час труда характеризуется либо величиной заработной платы, либо величиной прибыли. Владелец автомобиля, являясь специалистом в своей сфере деятельности, которая обеспечивает ему определенный уровень благосостояния, невольно соизмеряет время, затраченное им на работы при ремонте и обслуживании собственного автомобиля с тем, какой доход он получил бы за то же время, работая по специальности. Чаще всего с учетом качества выполненной работы специалисты среднего достатка склоняются к необходимости обращения на СТО. Система сервисного - центра предназначено для использования менеджерами автомобильных центров для: − работы с клиентами; − подбора диагностики и ремонта автомобиля; − подготовки заказов клиентов; Информационно-аналитический раздел в системе должен предоставлять отчеты, включающие расчеты выполнения самых популярных заказов диагностик, а также прибыль центра. Данные в системе представляются в виде диаграмм, а так же есть возможность подачи отчета на печать.1.2 Техническое задание на разработку автоматизированной подсистемы автомобильного сервисного - центраВведениеНастоящее техническое задание (ТЗ) на разработку автоматизированной подсистемы сервисного - центра предназначено для использования менеджерами сервисного - центра для: − работы с клиентами; − подбора диагностик; − регистрации заказов клиентов; − внесения информации в базу данных. Программа позволяет ускорить работу менеджера сервисного центра за счет автоматизации большого количества задач, отнимающих большую часть времени, что непременно влечет за собой повышение качества обслуживания клиентов. Основание для разработкиИнформационная система автомобильного сервисного центра разрабатывается на основе выполнения курсового проекта в рамках курса «Проектирование информационных систем». Назначение разработкиСистема предназначена для решения следующих задач: Хранение информации и сотрудниках и клиентах сервисного центра. Выбор клиентом предоставляемых услуг салона. Предложение сотрудниками бонусных программ клиентам. Контроль за выполнением работы сервиса. Требования к программному изделию Система должна обеспечивать следующие функции: 1. Ввод, вывод, редактирование, хранение, печать информации о клиентах: − ФИО клиента; − Паспортные данные; − Телефон; 2.Ввод, вывод, редактирование, хранение, печать информации о сотрудниках и их полномочиях: − ФИО сотрудника; − имя в системе; − пароль; − должность. Ввод, вывод, редактирование, хранение, печать информации о транспортных средствах: − техническое состояние; − гос. номер; − марка; − цвет. Ввод, вывод, редактирование, хранение, печать информации о диагностике:− Название; − Дата; − Номер сотрудника; − Номер клиента. 5. заказах: Ввод, вывод, редактирование, хранение, печать информации о − Дата; − Сумма; − Номер диагностики. 6. товаре: Ввод, вывод, редактирование, хранение, печать информации о − Название; − Номер поставщика. 7. Проверка внесенных данных в необходимые поля. В случае недостаточных введенных данных будет вызвано уведомление об ошибке.8. Вывод полученных расчетов. Требования к надежности Система должна: проводить контроль вводимой информации; блокировать некорректные действия пользователя при работе с системой; обеспечивать целостность данных. Условия эксплуатацииИспользовать систему будут пользователи средней и низкой квалификации. Интерфейс системы максимально приближен к интерфейсам подобных систем. Ввод информации осуществлен в унифицированной форме. Требования к составу и параметрам технических средствНастоящая система должна работать на компьютерах IBM PC. Оперативная память на каждом компьютере, не менее 128 Мб. Свободное место на жестком диске не менее 10Гб. Требования к информационной и программной совместимостиПрограммное изделие должно работать на компьютере под управлением ОС семейства WIN 32. Для переноса программы не должны требоваться специальные программные и аппаратные средства. Требования к маркировке и упаковкеГотовое программное изделие и документация поставляется на компакт-дисках в стандартной упаковке. Один комплект программной документации должен быть распечатан с помощью лазерного принтера на листах формата А4 и иметь типографский переплет. Требования к транспортированию и хранению Требования к транспортированию и хранению программного изделия совпадают с аналогичными требованиями, предъявляемыми к компактдискам.Требования к программной документации Программная документация должна содержать следующие документы (см. ГОСТ 19.101-77): 1.Программные документы: Спецификация (ГОСТ 19.202-78); Текст программы (ГОСТ 19.401-78); Описание программы (ГОСТ 19.402-78); Пояснительная записка (ГОСТ 19.404-79); 2.Эксплуатационные документы: Ведомость эксплуатационных документов (ГОСТ 19.507-79); Формуляр (ГОСТ 19.501-78); Описание применения (ГОСТ 19.502-78); Руководство системного программиста (ГОСТ 19.503-79); Руководство программиста (ГОСТ 19.504-79); Руководство оператора (ГОСТ 19.505-79); Требования к перечисленным документам не отличаются от требований, определенных в ЕСПД. 1.3 Технико-экономическое обоснование разработки автоматизированной подсистемы автомобильного сервисного – центраВ результате создания подсистемы должны быть улучшены следующие основные источники экономической эффективности: − время сбора и первичной обработки исходной информации; − время, затрачиваемое на информационно-аналитическую деятельность; информационный автоматизированный сервисный − ускорить работу менеджера сервисного - центра за счет автоматизации большого количества задач; − увеличение скорости поиска информации и подготовки отчетов; На создание и внедрение подсистемы ожидаются следующие затраты: средства для разработки информационной системы; установка удаленного сервера БД; компьютерная техника (компьютеры, принтеры, сетевое оборудование); В таблице 1 выделены основные элементы затрат на разработку подсистемы автомобильного сервисного - центра. Таблица 1 – Элементы затрат на разработку Элементы затрат Стоимость, руб. Материальные затраты 1000 Основная и дополнительная зарплата 10000 Отчисления на социальные нужды 1000 Амортизация инструментальных разработчика средства 250 Накладные расходы 750 Всего: 13000 Таким образом, в данной главе на основе выявленного системного анализа было разработано ТЗ на создание подсистемы, а также выделены необходимые элементы затрат на реализацию. Глава 2. Проектирование и разработка информационной системы2.1 Проектирование функциональных моделейРазработка функциональных моделей производилась с использованием методологий IDEF0, IDEF3 и DFD. Методология функционального моделирования IDEF0 основана на методологии описания системы в целом как множества взаимозависимых действий или функций. Методология IDEF3 обычно используется для детализации функциональных блоков IDEF0, не имеющих диаграмм декомпозиции IDEF0. Таким образом, методология IDEF3 предназначена для описания процессов в виде упорядоченной последовательности событий с одновременным описанием объектов, имеющих непосредственное отношение к процессу. В данной курсовой работе на основе нотации IDEF0 была разработана контекстная диаграмма, которая показывает входные и выходные ресурсы, правила управления и механизм управления (Рисунок 1).Рисунок 1 — Контекстная диаграмма системы (IDEF0) Декомпозируем контекстную диаграмму на 4 функциональных блоков (Рисунок 2): «Прием заказа от клиента»; «Диагностика»; «Обработка заказа подготовка к выполнению»; «Формирование отчетных документов».Рисунок 2 — Диаграмма декомпозиции контекстной диаграммы (IDEF0)Декомпозируем функциональный блок «Прием заказа от клиента» еще на 4 действия. (Рисунок 3):Рисунок 3 — Декомпозиция функционального блока «Прием заказа от клиента» (IDEF0) Исследуя предметную область оказалось необходимым разбиение пункта «Занесение данных клиента в БД» на определенные шаги при помощи методологии IDEF3 (Рисунок 4). Стандарт IDEF3 предназначен для документирования технологических процессов, происходящих на предприятии, и предоставляет инструментарий для наглядного исследования и моделирования их сценариев.Рисунок 4 — Декомпозиция функционального блока «Занесение данных клиента в БД» (IDEF3) Декомпозируем функциональный блок «Диагностика автомобиля» (Рисунок 5).Рисунок 5 — Декомпозиция функционального блока «Диагностика автомобиля» Необходимо декомпозировать функциональный блок «Выполнение диагностики» при помощи IDEF3 (Рисунок 6). Рисунок 6 — Декомпозиция функционального блока «Выполнение диагностики» (IDEF3) Декомпозируем функциональный блок «Обработка заказа, подготовка к выполнению» еще на 3 действия (Рисунок 7): Выбор заказа из БД; Оценка состояния авто; Определение этапов работы.Рисунок 7 — Декомпозиция функционального блока «Обработка заказа, подготовка к выполнению» (IDEF0) Декомпозируем функциональный блок «Формирование отчетных документов» (Рисунок 8).Рисунок 8 — Декомпозиция «Формирование отчетных документов» (IDEF0)На основе нотации DFD была разработана контекстная диаграмма, которая показывает входные и выходные ресурсы, правила управления и механизм управления (Рисунок 9).USED AT:AUTHOR: DATE: 07.05.2015PROJECT: Управление REV: 19.05.2015 сервисным центромNOTES: 1 2 3 4 5 6 7 8 9 10WORKINGREADER DATECONTEXT:TOPDRAFTRECOMMENDEDPUBLICATIONОтчетыNODE: A-0TITLE: Управление сервисным центромNUMBER:Рисунок 9 — Контекстная диаграмма системы (DFD) Декомпозируем контекстную диаграмму «Управление сервисным центром» (Рисунок 10): Рисунок 10 — Декомпозиция контекстной диаграммы «Управление сервисным центром» (DFD) Далее декомпозируем функциональный блок «Прием заказа» на 3действия (Рисунок 11):Рисунок 11 - Декомпозиция функционального блока «Прием заказа» (DFD)Декомпозируем функциональный блок «Предоставление вариантов клиенты» (Рисунок 12):Рисунок 12 — Декомпозиция функционального блока «Предоставление вариантов клиенты» (DFD) Декомпозируем функциональный блок «Выполнение заказа» (Рисунок 13):Рисунок 13 — Декомпозиция функционального блока «Выполнение заказа» (DFD) Декомпозируем функциональный блок «Составление отчетов, документации» (Рисунок 14):Рисунок 14 — Декомпозиция функционального блока «Составление отчетов, документации» (DFD) 2.2 Разработка информационной моделиЦель моделирования данных (информационного моделирования) состоит в обеспечении разработчика ИС концептуальной схемой БД в форме одной модели или нескольких локальных моделей. Наиболее распространенным средством моделирования данных являются диаграммы ERD (диаграммы «сущность-связь»).Диаграмма уровня сущностей и атрибутов, в нотации IDEF1X логического уровня модели ERwin (Рисунок 15):Рисунок 15 — ERD-диаграмма в нотации IDEF1X логический уровень. В ERwin существуют два уровня представления и моделирования - логический и физический. Логический уровень означает прямое отображение фактов из реальной жизни. Например, люди, столы, отделы, компьютеры являются реальными объектами. Они именуются на естественном языке, с любыми разделителями слов. Физический уровень модели ERwin составляют целевая СУБД, имена объектов, типы данных и индексы. Определив физическое описание модели, можно сгенерировать БД. В результате анализа была разработана физическая модель базы данных (Рисунок 16)Рисунок 16 — ERD- диаграмма в нотации IDEF1X физический уровень Физический уровень модели ERWin составляют целевая СУБД, имена объектов, типы данных и индексы. Создание и регистрация базы данных с помощью утилиты IBExpert, изображены на рисунке 17 – 18. Рисунок 17 – Создание базы данных в утилите IBExpert Рисунок 18 – Регистрация базы данных в утилите IBExpert Просмотр созданных таблиц, с помощью «Дизайнера базы данных» (рисунок 19). Рисунок 19 – Дизайнер базы данных2.3 Разработка пользовательского интерфейсаИнтерфейс является неотъемлемой частью программ и информационных систем. Интерфейс пользователя— разновидность интерфейсов, в котором одна сторона представлена человеком (пользователем), другая — машиной/устройством. Представляет собой совокупность средств и методов, при помощи которых пользователь взаимодействует с различными, чаще всего сложными, машинами, устройствами и аппаратурой. Поскольку интерфейс есть совокупность, то он состоит из элементов, которые, сами по себе, также могут состоять из элементов (так, экран дисплея может содержать в себе другие окна, которые, в свою очередь, могут содержать панели, кнопки и прочие интерфейсные элементы). Особое и отдельное внимание в интерфейсе пользователя традиционно уделяется его эффективности и удобству пользования. Понятный, удобный, дружественный — его основные характеристики. Основные этапы разработки интерфейса: Определение основных функций программы Реализация шаблона интерфейса Утверждение модели интерфейса 4.Создание интерфейса с помощью средств программирования (компоненты, меню) 5. Программная реализация действий компонент интерфейса. Как результат - рабочее приложение. Программа «автоматизированной подсистемы автомобильного сервисного центра» позволяет пользователю вводить и просматривать, хранить информацию в базе данных, изменять и удалять ее, осуществлять сортировку, фильтрацию и поиск информации по всей базе. На рисунках 20 – 24 показаны графические интерфейсы вкладок с таблицами.Рисунок 20 – Вкладка «Клиенты» Рисунок 21 – Вкладка «Поставщики»Рисунок 22 – Вкладка «Сотрудники»Рисунок 23 – Вкладка «Заказ»Рисунок 24 – Вкладка «Диагностика»В данной главе на основе ТЗ были спроектированы функциональные и информационные модели подсистемы, разработан пользовательский интерфейс, а также представлены твердые копии основных модулей подсистемы.Глава 3. Инструкция по эксплуатации выполнение программыДля начала работы с приложением необходимо запустить программу, открыть файл Project1.exe (рисунок 25). Рисунок 25 – папка с файлом Project1.exe После запуска открывается основное окно программы (рисунок 26).Рисунок 26 – Основное окно программыВкладка «Клиенты» на форме представляется в виде таблицы, которая содержит информацию о всех клиентах автосалона. Ниже таблицы расположена навигационная панель, с помощью которой можно передвигаться по записям таблицы. Информацию о клиентах можно фильтровать, необходимо ввести значения в поля «От» и «До», далее следует нажать кнопку «Фильтр». На рисунке 27 представлена фильтрация по фамилиям от «В» до «П». Для того, что бы отобразилась все записи необходимо нажать кнопку «Без фильтра». Что бы очистить поля ввода – нажать кнопку «Очистить».Рисунок 27 – Фильтрация данныхПоиск информации по клиентам осуществляется на панели «Поиск». В поле для поиска надо ввести фамилию клиента или несколько букв. В таблице отобразиться найденная информация (рисунок 28). Поиск осуществляется с начала и внутри фамилий. Рисунок 28 – Поиск данныхДля просмотра отчета по клиентам необходимо нажать кнопку «Отчет» (рисунок 29). Рисунок 29 – Отчет по клиентамДля регистрации нового клиента в базе данных необходимо выбрать значение «Добавить». Поля, которые необходимы для заполнения, будут обозначаться *. Кнопка «Добавить» будет активной, остальные заблокированы. В поля необходимо ввести данные и нажать «Добавить» (рисунок 30).Рисунок 30 – Добавление клиентов в базу данныхРисунок 31 – Добавленный клиентПри удалении записи, необходимо выбрать значение «Удалить» и ввести в поле № - номер удаляемого клиента (рисунок 32).Рисунок 32 – Выбранная запись для удаленияРисунок 33 – Выполненное удаление Так же в таблице можно изменять данные записи, выбрав значение «Изменить». Поля для изменения обозначаются *, в которые вводим значения. Далее нажимаем кнопку «Изменить» (рисунок 34).Рисунок 34 – Измененная записьВкладка «Аналитические данные» показывает прибыль сервисного – центра. Рисунок 35 – Вкладка «Аналитические данные»В данной главе была разработана инструкция по эксплуатации, в которой наиболее подробно описана работа пользователя с программой. Работа программы, описанная в главе, возможна со всеми вкладками. На вкладке «Аналитические данные» представлен график прибыли от заказов. График показывает зависимость прибыли салона от заказов клиентов. Программа была протестирована и полностью готова к использованию.ЗаключениеВ ходе выполнения работы были достигнуты все поставленные цели и задачи: − проведен анализ предметной области; − разработаны функциональные модели автоматизированной подсистемы (АП) сервисного центра; − разработана информационная модель АП сервисного центра; − разработано программное обеспечение для АП сервисного центра. Работа позволила приобрести навыки создания моделей с использованием методологии IDEF0, IDEF3, DFD, а также навыки разработки пользовательского интерфейса для автоматизированной системы, основанных на клиент-серверной технологии с использованием СУБД Firebird. Разработанная автоматизированная подсистема обладает всей необходимой для работы функциональностью и вполне может стать основой в работе сервисного - центра, так как, интерфейс программы является очень удобным для работы с БД. В результате выполнения работы приобретены навыки работы с учебной, справочной и методической литературой, что помогло в выполнении практической части.Список литературыГахов Р.П. Методы и средства проектирования информационных систем и технологий: Учебно-методический комплекс Белгород, 2013.Козлов А.С. Проектирование и исследование бизнес-процессов: Учебное пособие – Москва: Флинта, 2011. - 268 с. Кирилов В.В. / Громов Г.Ю. Введение в реляционные базы данных - Петербург.: БХВ – Петербург, 2012. - 362 с. Репин В. - Бизнес-процессы. Моделирование, внедрение, управление. - Москва: Флинта, 2013. - 480 с.ISO/IEC 12207:2010 (ГОСТ P – 2010). ИТ. Процессы жизненного цикла программных средствГолицына О.Л. Информационные системы: Учебное пособие/ О.Л. Голицына, Н.В. Максимов, И.И. Попов – М.: Форум, 2016Гвоздева В.А., Лаврентьева И.Ю. Основы построения автоматизированных информационных систем: Учебник. Серия: проф. Образование М.: «ФОРУМ» 2020.Мидоу, Чарльз Т. Анализ информационно-поисковых систем: Введение для программистов/ Ч. Мидоу; пер. с англ. Б.Е. Вербицкого и Л.А. Какунина – Москва: Мир, 2018-368 с.: ил.; 22 см.Куликов, С.С. К90 Реляционные базы данных в примерах: практическое пособие для программистов и тестировщиков/ С.С. Куликов. – Минск: Четыре четверти, 2020 – 424 с.Троелсен, Эндрю, Джепикс, Филипп Т70 Язык программирования С# 7 и платформы .NET и .NET Core, 8-е изд: Пер с англ. – СПб.: ООО «Диалектика», 2018 – 1328 с. : ил. – Парал. тит. Англ.Размещено на Allbest.ru