Разработка базы данных «Техническая поддержка IT-помощник»

Первая таблица формы – это таблица заявок. Тут есть 4 фильтра: «Фильтрация по состоянию заявки», «Фильтр по району», «Фильтр по клиенту», «Фильтр по мастеру». Поставив галочку и заполнив поле ниже фильтра, таблица отфильтровывается по заданным параметрам. Вторая таблица формы отображает работы входящую в заявку, при перемещении курсора в 1 таблице, работы подстраиваются под выделенную заявку. Также при помощи нижней панели мы можем добавлять и удалять работы из заявки.

Помимо этого форма предоставляет возможность просмотра отчета обо всех заявках базы данных. Для этого необходимо нажать кнопку «Отчет обо всех заявках»(Приложение 2).

Последний подпункт пункта меню «Заявки» – «Свободные заявки» откроет форму с графиками: «График невыполненных заявок по районам»,    «График невыполненных заявок по мастерам».(Приложение 2).

Перейдем к 4 пункту меню «Мастера». Он обладает 2 подпунктами: «Перечень мастеров» и «Отбор заявок по ФИО».(Рис. 2.9)

Рис. 2.9 Формы подпунктов пункта меню «Мастера»

Форма «Мастера» позволяет редактировать таблицу Мастера, осуществлять поиск по ФИО мастера, а также выводит Отчет о выручке по дням на каждого из мастеров.(Приложение 2).

Форма «Отбор заявок по ФИО» позволяет отфильтровать заявки отдельно для каждого мастера.

Последний пятый пункт меню «Бонусы» имеет также 2 подпункта «Скидки» и «Акции»(Рис. 2.10). Каждый из которых позволяет редактировать аналогичную таблицу в базе данных.

Рис. 2.10 Формы подпунктов пункта меню «Бонусы»

2.5. Тестирование программного продукта

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

Такой процесс формальной проверки, или верификации, может доказать, что дефекты отсутствуют с точки зрения используемого метода. (То есть, нет никакой возможности точно установить или гарантировать отсутствие дефектов в программном продукте с учётом человеческого фактора, присутствующего на всех этапах жизненного цикла программы).

Существует множество подходов к решению задачи тестирования и верификации программного продукта, но эффективное тестирование сложных программных продуктов – это процесс в высшей степени творческий, не сводящийся к следованию строгим и чётким процедурам или созданию таковых.

С точки зрения ISO 9126, качество программного обеспечения можно определить как совокупную характеристику исследуемого программного продукта с учётом следующих составляющих:

• Надёжность
• Сопровождаемость
• Практичность
• Эффективность
• Мобильность
• Функциональность

 

Проведя тестирование программы, мы получили результаты, говорящие нам о том, что данное приложение является работоспособным, практичным, удобным. Более полные сведения приведены в таблице 2.1.

 

Таблица 2.1. Результаты тестирования

№	Критерий	Оценка
1	Надежность	Удовлетворительно
2	Сопровождаемость	Хорошо
3	Практичность	Хорошо
4	Эффективность	Хорошо
5	Мобильность	Удовлетворительно
6	Функциональность	Хорошо

 

 

Заключение

В ходе выполнения курсовой работы была разработана система учета и контроля заявок, поступающих в службу технической поддержки. Были решены поставленные задачи и выполнены все этапы разработки базы данных.

На этапе проектирования базы данных был проведен анализ существующего программного обеспечения в сфере управления сервисным центром, а также произведено проектирование базы данных на физическом, логическом и концептуальном уровнях. В ходе анализа предметной области были выяснены ключевые аспекты деятельности, и выявлен необходимый набор функций, подлежащий реализации. При концептуальном проектировании базы данных были выделены соответствующие сущности и связи, для которых была построена ER-диаграмма. В ходе логического проектирования были определены атрибуты каждой сущности и домены атрибутов, а также создана логическая схема проекта.

При выборе целевой СУБД был проведен анализ двух систем: Microsoft Access 2007 и Oracle. Для выполнения курсовой работы была выбрана СУБД Microsoft Access. В ней была создана база данных и ее физическая модель.

На этапе разработки программного продукта была построена его структура, реализованы бизнес-правила, составлены руководства программиста и оператора, проведено тестирование программы.  Для реализации бизнес правил были составлены SQL-запросы для вывода необходимой информации. Руководство программиста описывает функционал программы, её инструменты и возможности, а также сообщения об ошибках, выдаваемые программой, при нарушении правил заполнения. В руководстве оператора описаны минимальные системные требования, порядок работы с приложением. На этапе тестирования была произведена оценка программного продукта по различным показателям. Результаты тестирования были проанализированы и соответствующие недостатки устранены.  

Представленная курсовая работа является базой данных, разработанной с помощью прикладных программ, таких как Embarcadero RAD Studio 2010 и Microsoft Office Access 2007, объединяющих между собою реализацию схем потоков данных, их зависимость друг от друга. Проект основан на автоматизации процессов повышающих эффективность работы небольшого сервисного центра технической поддержки, в котором отражается сущность связей, система запросов, хранение информации, составление отчетов базы данных.

 

Список используемых источников

1. Свободная энциклопедия [Электронный ресурс] http://ru.wikipedia.org/

2. Основы проектирование базы данных [Электронный ресурс] http://citforum.ru/database/dbguide/

3. 1С Управление сервисным центром [Электронный ресурс] http://solutions.1c.ru/catalog/service-center

4. Система управления заявками vsDesk [Электронный ресурс] http://vsdesk.ru/

5. Тестирование программного обеспечения [Электронный ресурс]

http://www.razlib.ru/kompyutery_i_internet/tehnologii_programmirovanija/p13.php

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Приложение 1. Техническое задание на разработку программного продукта

 

1. Введение

Современным небольшим сервисным центрам поступает большое количество заявок, которые необходимо регистрировать, хранить, а также контролировать их выполнение. Данные продукт и призван решать вышеописанные задачи. 

2. Основания для разработки

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

3. Назначения разработки

Программный продукт предназначен для введения учета и контроля выполнения заявок небольшого сервисного центра.

4. Требования к программе или  программному изделию

4.1. Требования к функциональным  характеристикам 

Программный продукт должен обладать следующими функциями:

• Регистрация заявок
• Отображение списка клиентов
• Добавление/Изменение/Удаление данных
• Поиск данных
• Построение графиков «Лучшие клиенты» и «Графики невыполненных заявок»
• Генерация отчета по выручке от клиентов, и мастеров.

4.2. Требования к надежности

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

4.3. Условия эксплуатации

Нет требований.

4.3. Требования к составу  и параметрам технических средств

Процессор с тактовой частотой 1ГГц и выше

512 Мб оперативной памяти

100 Мб свободного места на жестком диске

4.4 Требования к информационной программной совместимости 

Операционная система Microsoft Windows XP/7

Стадии и этапы разработки

• анализ предметной области
• концептуальное и логическое проектирование БД;
• выбор целевой СУБД;
• физическое проектирование БД;
• создание части программного продукта;
• написание основного кода программы;
• формирование SQL запросов;
• построение отчетов и графиков;
• отладка программы;
• оформление пояснительной записки

 

Приложение 2. Графики и отчеты

Рис.1 Отчет «Прибыль от клиентов»

 

Рис.2 Отчет «Информация о клиентах»

Рис.3 Отчет о свободных заявках

Рис.4 Отчет о заявках

 

Рис.5 Отчет «Выручка по дням на каждого мастера»

Рис.6 График лучших клиентов

Рис. 7 Графики невыполненных заявок по районам и мастерам

Рис.8 График количества заявок по датам у выбранного мастера