Программные средства информационной системы учета и анализа дорожнотранспортных происшествий

Название	Программные средства информационной системы учета и анализа дорожнотранспортных происшествий
Дата	30.05.2022
Размер	2.76 Mb.
Формат файла
Имя файла	qtRHfTETOPv8.pdf
Тип	Документы #557324
страница	3 из 3

1 2 3

10 Модель реализации клиентского приложения
Модель реализации описывает, как реализуются в виде компонентов элементы модели проектирования.
Для отображения реализации используется диаграмма компонентов.
Диаграмма компонентов представлена на рисунке 25.

42
Рисунок 25 – Диаграмма компонентов
Исходный код клиентского приложения на языке программирования C#
приведен в приложении Б.
Одним из способов моделирования статического вида системы с точки зрения развертывания является диаграмма развертывания.
Диаграмма развертывания представлена на рисунке 26.
Рисунок 26 – Диаграмма развертывания
На рисунке 26 показано, что клиентское приложение разворачивается на рабочих станциях пользователей, а база данных разворачивается на отдельном сервере.

43
3 Контроль качества программного обеспечения
Тестирование программного обеспечения является очень важным и в то же время трудоемким видом деятельности. Тестирование – это прежде всего оценка промежуточных продуктов, созданных в процессе разработки программного обеспечения. Это гораздо более широкое поле деятельности,
нежели просто проверка некоторых частей или программной системы в целом с целью определения степени ее соответствия техническим требованиям [12].
В данной выпускной квалификационной работе была выбрана методология функционального тестирования.
11
Функциональное тестирование
Функциональное тестирование – это тестирование программного обеспечения в целях проверки реализуемости функциональных требований, то есть способности программного обеспечения в определенных условиях решать задачи, нужные пользователям. Функциональные требования определяют, что именно делает программное обеспечение, какие задачи оно решает [13].
Функциональное тестирование предполагает составление плана тестирования, который строится на основе вариантов использования и включает в себя описание тестов и их результаты.
План тестирования приведен в таблице 5.
Таблица 5 – План тестирования
Вариант использования
Тест
Результат
Добавить водителя с
ВУ
Запускаем приложение. Переходим в окно регистрации нового ДТП. Заполняем информацию о ДТП. Нажимаем кнопку
«Далее». Появляется окно редактирования участников ДТП. Нажимаем кнопку
«Добавить водителя с ВУ». Выбираем необходимую информацию. Нажимаем кнопку «Сохранить».
Тест выполнен.
Водитель с ВУ
добавлен в список участников ДТП.
Продолжения таблицы 5

44
Вариант использования
Тест
Результат
Добавить водителя без ВУ
Запускаем приложение. Переходим в окно регистрации нового ДТП. Заполняем информацию о ДТП. Нажимаем кнопку
«Далее». Появляется окно редактирования участников ДТП. Нажимаем кнопку
«Добавить водителя без ВУ». Выбираем необходимую информацию. Нажимаем кнопку «Сохранить».
Тест выполнен.
Водитель без ВУ
добавлен в список участников ДТП.
Добавить водителя пешехода
Запускаем приложение. Переходим в окно регистрации нового ДТП. Заполняем информацию о ДТП. Нажимаем кнопку
«Далее». Появляется окно редактирования участников ДТП. Нажимаем кнопку
«Добавить пешехода».
Вводим необходимую информацию. Нажимаем кнопку «Сохранить».
Тест выполнен.
Пешеход добавлен в список участников
ДТП. (рисунок В.1).
Поиск водителя
Запускаем приложение. Переходим в окно регистрации нового ДТП. Заполняем информацию о ДТП. Нажимаем кнопку
«Далее». Появляется окно редактирования участников ДТП. Нажимаем кнопку
«Добавить водителя с ВУ». В поле
«Паспорт» вводим номер паспорта водителя. Нажимаем кнопку «Найти водителя».
Тест выполнен.
Водитель с указанным номером паспорта найден (рисунок В.2).
Поиск ТС
Запускаем приложение. Переходим в окно регистрации нового ДТП. Заполняем информацию о ДТП. Нажимаем кнопку
«Далее». Появляется окно редактирования участников ДТП. Нажимаем кнопку
«Добавить водителя с ВУ». В поле
«Регистрационный номер» вводим регистрационный номер ТС. Нажимаем кнопку «Найти ТС».
Тест выполнен. ТС с указанным номер было найдено (рисунок В.3).
Зарегистрировать новое ДТП
Запускаем приложение. Переходим в окно регистрации нового ДТП. Заполняем информацию о ДТП. Нажимаем кнопку
«Далее». Появляется окно редактирования участников ДТП. Заполняем участников
ДТП. Далее нажимаем кнопку
«Зарегистрировать ДТП».
Тест выполнен. ДТП
было успешно зарегистрировано
(рисунок В.4).
Удалить карточку
Запускаем приложение. Выбираем нужную нам карточку ДТП. Нажимаем кнопку
«Удалить карточку».
Тест выполнен.
Карточка ДТП была успешно удалена.

45
На основе анализа результатов тестирования можно сделать вывод, что разработанные программные средства информационной системы учета и анализа дорожно-транспортных происшествий работают корректно.
12 Метрики кода
Применение метрик позволяет руководителям проектов и предприятий изучить сложность разработанного или даже разрабатываемого проекта,
оценить объем работ, стилистику разрабатываемой программы и усилия,
потраченные каждым разработчиком для реализации того или иного решения
[14].
Примером часто используемой метрики является комплексный показатель качества кода – Maintainability Index. Рассчитывается метрика по формуле:
),
171
/
100
*
))
ln(
*
2 16
*
23 0
)
ln(
*
2 5
171
(
,
0
max(
LoC
CC
HV
MI




где HV (Halstead Volume) – вычислительная сложность;
CC (Cyclomatic Complexity) – показывает структурную сложность кода,
т.е. количество различных ветвей в коде;
LoC (Lines of Code) – количество строк кода.
Комплексный показатель качества кода может принимать значения от 0 до
100 и показывает относительную сложность поддержки кода. Чем больше значение этой метрики, тем легче поддерживать код.
Для определения вычислительной сложности программы сначала следует рассчитать словарьи длину программы, а затем вычислить на их основе
HV
Словарь программы рассчитывается по формуле:
2 1





,
где
1

– число простых операторов и операций в программе;
2

– число простых операндов (констант и переменных) в программе.
Длина программы рассчитывается по формуле:
2 1
N
N
N


,

46
где
1
N
– общее число простых операторов и операций в программе;
2
N
– общее число простых операндов в программе.
Вычислительная сложность рассчитывается по формуле:

2
log
H N
V 
,
Для определения структурной сложности программы сначала следует построить управляющий граф программы. Затем на его основе определить
СС
по формуле:
p
v
e
CC




2
,
где
e – число дуг ориентированного графа программы;
v – число вершин ориентированного графа программы;
p– число компонент связности ориентированного графа программы.
Структурную сложность программы можно рассчитать и другим способом, представленным в формуле:
СС = (количество операторов if) + (количество операторов цикла) +1.
Если полученное значение СС больше 10, то это свидетельствует о структурной сложности программы, что затрудняет ее функциональное тестирование (методом «белого ящика») и требует упрощения программы.
Visual Studio позволяет вычислять метрики автоматически. Произведем вычисления для разрабатываемого приложения. Метрики исходного кода представлены на рисунке 27.
Проанализируем полученные результаты. В данном проекте комплексный показатель кода (MI) находится на высоком уровне. Средняя отметка комплексного показателя составляет 80. Это свидетельствует об относительной простоте поддержки исходного кода. Структурная сложность кода (СС)
находится на среднем уровне.
В данном проекте большой глубиной наследования обладают классы- формы, описывающие графический интерфейс приложения, остальные классы обладают глубиной наследования не более 2 [15].

47
Рисунок 27 – Метрики исходного кода проекта
Исходя из полученных результатов метрик кода можно сделать вывод, что показатели метрик соответствуют норме.

48
Заключение
В ходе выполнения выпускной квалификационной работы разработаны программные средства информационной системы учета и анализа дорожно- транспортных происшествий, состоящие из клиентского приложения и серверной части.
Проведено концептуальное, логическое и физическое проектирование реляционной базы данных, проектирование графического интерфейса.
Клиентское приложение реализовано с помощью языка C# в интегрированной среде разработки Visual Studio 2012. В серверной части приложения с помощью языка SQL реализована база данных, которая включает в себя таблицы, представления и хранимые процедуры. База данных реализована в СУБД MS SQL Server 2012.
На этапе анализа качества кода проведено функциональное тестирование.
На основе анализа результатов тестирования можно сделать вывод, что разработанное программное обеспечение работает корректно.
В ходе выполнения работы также проведено планирование проекта.
Длительность выполнения проекта равна 118 дней, бюджет равен 168 352
рубля.
Таким образом, в результате выполнения выпускной квалификационной работы разработаны программные средства, отвечающие требованиям технического задания.

49
Список использованных источников
1. Фаттахов Т. А. Коррупция как фактор высокой смертности от дорожно-транспортных происшествий в России // Мониторинг общественного мнения: экономические и социальные перемены, 2015. № 4. С.66-95.
2. Федеральный закон от 10.12.1995 № 196-ФЗ «О безопасности дорожного движения» / Собрание законодательства РФ, 11.12.1995, N 50, ст. 4873.
3. Учет и анализ дорожно–транспортных происшествий ГИБДД //
Magref. 2013. [Электронный ресурс]. URL: http://magref.ru/uchet-i-analiz- dorozhno-transportnyih-proisshestviy-gibdd/ (дата обращения: 10.05.2017).
4. Система учета и анализа ДТП // Титул. 2006. [Электронный ресурс].
URL:
http://titul2005.ru/index.php/mnuprogramm/mnutitul2005/41-uncategorised/
107-dtp (дата обращения: 10.05.2017).
5. Лафоре, Р. Объектно-ориентированное программирование в С++. / Р.
Лафоре. – СПб.: Издательство Питер, 2004. – 902 с.
6. Вендров, A.M. Проектирование программного обеспечения экономических информационных систем. / А.М. Вендров. – М.: Финансы и статистика, 2005. – 544 с.
7. Шарп, Джон. Microsoft Visual C#. Подробное руководство. 8-е изд. /
Джон Шарп. – СПб.: Питер, 2017. – 848 с.
8. Почему SQL Server data management system? / Microsoft. 2013.
[Электронный ресурс]. URL: https://www.microsoft.com/en/server-cloud/data- management/why.aspx (дата обращения 01.05.2017).
9. Microsoft Visual Studio Ultimate 2012 / Microsoft. 2013. [Электронный ресурс]. URL: https://www.microsoft.com/ru-RU/download/details.aspx?id=30678
(дата обращения 01.05.2017).
10. Лавренова, О.А. Функциональные требования к авторитетным данным : концептуальная модель : заключительный отчет / О.А. Лавренова под ред. Гленна Е. Патона – Санкт-Петербург : Российская национальная библиотека, 2011. – 115 с.

50 11. Конноли, Т. Базы данных: Проектирование, реализация и сопровождение. Теория и практика. Второе издание. / Т. Конноли, К. Бегг, А.
Страчан. – М.: Вильямс, 2000. – 1139 с.
12. Управление проектами // Википедия. 2001. [Электронный ресурс].
URL: https://ru.wikipedia.org/wiki/Управление_проектами (дата обращения:
01.05.2017).
13. Функциональное тестирование // Википедия. 2001. [Электронный ресурс]. URL: https://ru.wikipedia.org/wiki/Функциональное_тестирование (дата обращения: 01.05.2017).
14. Метрики кода программного обеспечения / PVS-Studio. 2017.
[Электронный ресурс].
URL:
https://www.viva64.com/ru/a/0045/
(Дата обращения: 01.05.2017).
15. Значения метрик кода / Microsoft. 2013. [Электронный ресурс]. URL:
https://msdn.microsoft.com/ru-ru/library/bb385914.aspx
(дата обращения:
01.05.2017)

1 2 3