---

Государственное бюджетное профессиональное образовательное учреждение
 «Волгоградский индустриальный техникум»
Самостоятельная работа студента 
по МДК 05.01.
Проектирование и дизайн информационных систем
09.02.07.(№ по журналу).ВТВ-1**
РАЗРАБОТКА ПОРТАЛА ДЛЯ ФИКСАЦИИ 
НАРУШЕНИЙ ПРАВИЛ ДОРОЖНОГО ДВИЖЕНИЯ
по предметной области
«Полиция России»

Студент		ФИО
Преподаватели		И.А. Бочарова 
		
Оценка		
Дата сдачи		
20**
РАЗДЕЛ 1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ
1.1. Сбор данных
Полиция России — это составная часть единой централизованной си-стемы Министерства внутренних дел Российской Федерации. 
Полиция предназначена 
1)	для защиты жизни, здоровья, прав и свободы человека, гражданина Российской Федерации, иностранных граждан, лиц без гражданства; 
2)	для противодействия преступности, охраны общественного порядка, собственности и для обеспечения общественной безопасности.
Согласно статьи 12. Обязанности полиции Федерального закона от 07.02.2011 N 3-ФЗ (ред. от 28.12.2024) «О полиции» на полицию возлага-ются следующие обязанности (некоторые из них):
1)	принимать и регистрировать (в том числе в электронной форме) за-явления и сообщения о преступлениях, об административных правонару-шениях, о происшествиях; выдавать заявителям на основании личных об-ращений уведомления о приеме и регистрации их письменных заявлений о преступлениях, об административных правонарушениях, о происшестви-ях; информировать заявителей о ходе рассмотрения таких заявлений и сообщений в сроки, установленные законодательством Российской Феде-рации;
2)	обеспечивать безопасность граждан и общественный порядок на улицах, площадях, стадионах, в скверах, парках, на транспортных маги-стралях, вокзалах, в аэропортах, морских и речных портах и других об-щественных местах; 
В разработке информационного ресурса заинтересованы следующие лица:
1)	заявитель (пользователь);
2)	сотрудник ГИБДД;
Каждый из стейкхолдеров на информационном ресурсе сможет:
1)	заявитель сможет:
	подать жалобу;
	просмотреть все свои жалобы в личном кабинете;
	просмотреть информацию о ходе рассмотрения заявления;
2)	сотрудник ГИБДД сможет:
	просматривать все жалобы;
	изменять статус в ходе рассмотрения жалобы.
Работу сотрудников ГИБДД регламентируют следующие документы:
	Федеральный закон ФЗ -N 3 от 07.02.2011 (ред. от 28.12.2024) «О полиции»;
	КоАП РФ, ст. 23.3.
	Закон РФ от 07.02.1992 N 2300-1 «О защите прав потребителей»;
	Закон №152-Ф3 «О персональных данных» часть 1 ст. 9 «Согласие на обработку персональных данных».
Сотрудники ГИБДД, занимающиеся фиксацией нарушений правил дорожного движения, ведут следующие документы:
	журнал учёта заявлений;
	отчёты по подаче заявлений.
1.2. Обоснование необходимости создания АС
Актуальность задачи заключается в повышении эффективности рабо-ты сотрудников ГИБДД по фиксации нарушений правил дорожного дви-жения, и удобство пользования как для заявителей, так и для сотрудников ГИБДД. 
Учитывая собранные данные, разработана модель бизнес-процесса, которая позволяет провести всесторонний анализ. Используя методологию функционального моделирования IDEF0, построена функциональная мо-дель, отображающая структуру и функции работы портала по фиксации нарушений правил дорожного движения, а также потоки информации и материальных объектов, связывающих эти функции (см. рисунок 1).
 
Рисунок 1 - Контекстная диаграмма 
Для контекстной диаграммы IDEF0 построена её декомпозиция с по-дробным описанием функций разрабатываемой системы (см. рисунок 2).
 
Рисунок 2 – Декомпозиция блока А0
Для блока А01 диаграммы IDEF0 построена её декомпозиция с по-дробным описанием функций разрабатываемой системы (см. рисунок 3).
 
Рисунок 3 - Декомпозиция блока А01
Для того чтобы сформулировать общие требования к функциональ-ному поведению проектируемой системы, построена диаграмма вариантов использования, на которой изображаются отношения между стейкхолде-рами (см. рисунок 4).
 
Рисунок 4 - Отношение стейкхолдеров
1.3. Предлагаемое решение
Учитывая вышеперечисленное, можно сделать вывод, что для повы-шения эффективности работы отдела полиции и привлечения сознательных граждан, необходимо разработать портал, который будет решать следу-ющие задачи:
	фиксация нарушений правил дорожного движения;
	выдача заявителям на основании личных обращений уведомления о приеме и регистрации их письменных заявлений об административных правонарушениях, о происшествиях; 
	информирование заявителей о ходе рассмотрения таких заявлений и сообщений;
	предусмотреть анимацию для улучшения пользовательского опыта.
РАЗДЕЛ 2. ТЕХНИЧЕСКОЕ ЗАДАНИЕ
2.1. Введение
Разрабатываемая информационная система называется «Нарушите-лям – Нет!», которая будет использоваться в сети интернет.
2.2. Основания для разработки
Разработка информационной системы ведётся на основании задания по ПМ05 Проектирование и разработка информационных систем государ-ственного бюджетного профессионального образовательного учреждения «Волгоградский индустриальный техникум».
Темой разработки является «Разработка портала для фиксации нарушений правил дорожного движения».
2.3. Назначение разработки
Разрабатываемый программный продукт предназначен для помощи полиции по своевременной фиксации нарушений правил дорожного дви-жения.
	фиксация нарушений правил дорожного движения;
	выдача заявителям уведомления о приеме и регистрации их письмен-ных заявлений об административных правонарушениях, о происшествиях; 
	информирование заявителей о ходе рассмотрения таких заявлений и сообщений. 
2.4	Требования к программе или программному изделию
2.4.1. Требования к функциональным характеристикам
Разрабатываемый программный продукт должен выполнять следу-ющие функции:
1)	На странице регистрации:
	содержать (хранить) информацию о пользователе: ФИО, телефон, адрес электронной почты, фото, логин и пароль;
	обеспечивать возможность ввода ФИО с использованием только сим-волов кириллицы и пробелы;
	обеспечивать возможность ввода телефона только в формате +7(XXX)-XXX-XX-XX;
	обеспечивать возможность ввода адреса электронной почты только в формате электронной почты;
	обеспечивать возможность ввода только уникального логина (логи-ны разных клиентов не должны совпадать);
	обеспечивать возможность создание пароля не менее 6 символов;
	предупреждать пользователя, что все поля обязательны для заполне-ния;
	предупреждать пользователя об ошибках валидации в информации, акцентирующей внимание;
	производить анимацию в виде всплывающей подсказки (для улучше-ния пользовательского опыта) при вводе в поля имени, фамилии и отчества с указанием, что необходимо использовать только символы кириллицы и пробелы;
	производить анимацию в виде всплывающей подсказки (для улучше-ния пользовательского опыта) при вводе телефона с указанием, что необ-ходимо только в формате +7(XXX)-XXX-XX-XX;
	производить анимацию в виде всплывающей подсказки (для улучше-ния пользовательского опыта) при вводе в поле email с указанием, что необходимо только в формате электронной почты;
	производить анимацию в виде всплывающей подсказки (для улучше-ния пользовательского опыта) при вводе пароля с указанием, что не менее 6 символов;
2)	На странице авторизации:
	предоставлять возможность ввода логина и пароля для зарегистри-рованных пользователей;
	выводить сообщения, акцентирующие внимание, при некорректном вводе логина и пароля;
3)	На странице формирования заявлений:
	предоставлять возможность входа на страницу формирования заяв-лений только авторизованным пользователям; 
	содержать (хранить) заявления с указанием: номера автомобиля и описания нарушения;
	акцентировать внимание пользователя и обеспечивать переход куда-то только при обязательном заполнении всех полей;
	формировать заявку (на основании заявления) с указанием: номера автомобиля, описания нарушения и статуса заявки (новое, подтверждено или отклонено);
4)	На странице заявлений:
	предоставлять возможность входа на страницу заявлений только ав-торизованным пользователям;
	производить просмотр заявлений пользователю, с указанием стату-сов;
	предоставлять возможность пользователю формировать новое заяв-ление;
5)	На странице администратора:
	предоставлять возможность входа на страницу администратора только по логину copp и паролю password;
	предоставлять возможность администратору просматривать все за-явления с указанием: ФИО подавшего, описание нарушения, номер авто-мобиля и статус заявления;
	предоставлять возможность администратору изменять только статус «новое» на «подтверждено» или «отклонено»;
Входные данные:
	ФИО;
	адрес;
	цена;
	почта;
	телефон.
Выходные данные:
	статус заявления.
Требования к временным характеристикам не предъявляются.
2.4.2 Требование к надёжности
Для надежного функционирования программного продукта, необхо-димы следующие требования к обеспечению надежного функционирова-ния:
	использование лицензионного программного обеспечения;
	обеспечение подключения к сети «Интернет»;
	производить тестирования на предмет уязвимости программного продукта и корректной работы программного продукта;
	в случае обнаружения каких-либо ошибок производить их устране-ние. 
Производить регистрацию пользователей для обеспечения безопас-ности их персональных данных.
2.4.3. Условия эксплуатаций
В рамках разработки информационной системы «Нарушителям – Нет!» требования к температуре окружающего воздуха, относительной влажности и шуму не предъявляются.
Для использования данного программного продукта пользователь должен иметь минимальные навыки работы с компьютером, уметь пользо-ваться интернетом и электронной почтой.
2.4.4 Требование к составу и параметрам технических средств
В рамках разработки информационной системы «Нарушителям – Нет!» требования к составу и параметрам технических средств не предъяв-ляются.
2.4.5 Требование к информационной программной совместимости
Требование к информационной программной современности не предъявляются.
2.4.6. Требования к маркировке и упаковке
В рамках разработки информационной системы «Нарушителям – Нет!» требования к маркировке и упаковке не предъявляются. 
2.4.7. Требования к транспортированию и хранению
В рамках разработки информационной системы «Нарушителям – Нет!» требования к транспортированию и хранению не предъявляются. 
2.5. Требования к программной документации
Разрабатываемый программный продукт должен сопровождаться следующей программной документацией:
	анализ предметной области;
	техническое задание;
	эскизный проект.
2.6. Технико-экономические показатели
В рамках разработки информационной системы «Нарушителям – Нет!» требования к технико-экономическим показателям не предъявляют-ся.
2.7. Стадии и этапы разработки
Стадии программ и программной документации устанавливаются по ГОСТ 19.102-77:
	разработка анализа предметной области: с **.**.20** по **.**.20**;
	разработка технического задания: с **.**.20** по **.**.20**;
	разработка эскизного проекта: с **.**.20** по **.**.20**;
	разработка программного продукта: с **.**.20** по **.**.20**;
2.8. Порядок контроля и приёмки
Приём информационной системы будет проходить во время зачёта в ГБПОУ ВИТ на МДК 05.01 Проектирование и дизайн информационных систем. 
Контрольные примеры разрабатываются студентом-разработчиком.
Если представленный информационный ресурс не удовлетворяет требованиям данного документа, то преподаватель должен предоставить обоснованный отказ от принятия работы с указанием деталей и четкой формулировкой требований.
РАЗДЕЛ 3. ЭСКИЗНЫЙ ПРОЕКТ
3.1. Структура входных – выходных данных
При разработке информационного ресурса, необходимо разработать базу данных «НН», в которой сохраняются данные для фиксации наруше-ний правил дорожного движения.
В таблице 1 описана структура входных – выходных данных табли-цы «Пользователи».
Таблица 1 – Пользователь
Поле	Тип	Ограничения	Описание
код_пользователя	Int(11)	PRIMARY Key	Счетчик, уникаль-ное значение
ФИО	Varchar(50)	NOT NULL	имя, не более 50 символов Обяза-тельное для запол-нения.
телефон	Varchar(25)	NOT NULL	номер для связи, не более 25 символов, обязательно для за-полнения.
почта	Varchar(50)	NOT NULL	адрес электронной почты, не более 50 символов, обяза-тельное для запол-нения.
фото	Varchar(150)	NULL	
логин			
пароль	Varchar(50)	NOT NULL	пароль, не более 50 символов Обяза-тельное для запол-нения.
В таблице 2 описана структура входных –выходных данных таблицы «Каталог».
Таблица 2 – Заявление
Поле	Тип	Ограниче-ния	Описание
id	Int(11)	PRIMARY Key	Счетчик, уникальное значение
Номер автомобиля	Varchar(50)	NOT NULL	Номер автомобиля, на котором совершено нарушение, обязатель-но для заполнения.
Описание наруше-ния	Varchar(50)	NOT NULL	Описание нарушения, обязатель-но для заполнения.
Статус	text		Статус заявки (новое, подтвер-ждено или отклонено)
3.2. Архитектура ИС

3.3. Макеты интерфейса программы
Программный продукт должен разрабатываться по следующим ма-кетам:
 
Рисунок 4 – Главная страница
 
Рисунок 5 –  Страница входа
 
Рисунок 6 –  Страница регистрации