автомобильные штрафы. 9варМарков (1). Техническое задание на разработку модуля Учет нарушений правил дорожного движения
 Скачать 91 Kb.
|
Техническое задание на разработку модуля «Учет нарушений правил дорожного движения» Листов 5
Пермь, 2022 Оглавление1. Введение 2 2. Основание для разработки 2 2.1. Основание для данной работы служит договор № 001 от 25 декабря 2021 г. 2 2.2. Наименование работы: 2 Модуль «Учет нарушений правил дорожного движения» 2 2.3. Исполнители: 2 2.4. Соисполнители: нет. 2 3. Назначение разработки 2 4. Технические требования 2 4.1. Требования к функциональным характеристикам. 2 4.1.1. Состав выполняемых функций. 2 4.1.2. Организация входных и выходных данных. 2 4.2. Требования к надежности. 3 4.3. Требования к составу и параметрам технических средств. 3 Минимальная конфигурация: 3 • тип процессора 3 • объем оперативного запоминающего устройства 3 • объем свободного места на жестком диске 3 Рекомендуемая конфигурация: 3 • тип процессора 3 • объем оперативного запоминающего устройства 3 • объем свободного места на жестком диске 3 100 Мб. 3 4.4. Требования к информационной и программной совместимости. 3 4.5. Требования к транспортировке и хранению. 3 4.6. Специальные требования: 3 5. Требования к программной документации 3 6. Технико-экономические показатели 4 7. Порядок контроля и приемки 4 8. Календарный план работ 4 Приложение A 5 1. ВведениеРабота выполняется в рамках разработки программного модуля «Учет нарушений правил дорожного движения» для оплаты нарушителями штрафов. Для каждой автомашины (и ее владельца) в базе хранится список нарушений. Для каждого нарушения фиксируется дата, время, вид нарушения и размер штрафа. При оплате всех штрафов машина удаляется из базы. 2. Основание для разработки2.1. Основание для данной работы служит договор № 001 от 25 декабря 2021 г.2.2. Наименование работы:Модуль «Учет нарушений правил дорожного движения»2.3. Исполнители:ООО «Проггер». 2.4. Соисполнители: нет.3. Назначение разработкиМодуль предназначен для занесения нарушителей в базу, в которой хранится список нарушений и возможность оплаты этих нарушений. 4. Технические требования4.1. Требования к функциональным характеристикам.4.1.1. Состав выполняемых функций.Разрабатываемое ПО должно обеспечивать: Удобное занесение нарушителей/машин в базу; Быстрый поиск по базе; Возможность оплаты штрафов; автоматическое удаление машин/нарушителей из базы, при оплате ими всех штрафов; 4.1.2. Организация входных и выходных данных.Исходные данные в систему поступают с камер фиксации нарушений, а также от сотрудников ГАИ. После, эти данные вносятся в базу данных. Основной режим использования системы — ежедневная работа. 4.2. Требования к надежности.Для обеспечения надежности необходимо проверять корректность вводимых данных. 4.3. Требования к составу и параметрам технических средств.
4.4. Требования к информационной и программной совместимости.Программа должна работать под управлением семейства операционных систем Windows (Windows 7/8/10/11), Linux (Ubuntu, Mint) и Mac OS. 4.5. Требования к транспортировке и хранению.Программа размещена в открытом доступе на сайте разработчика и имеет открытый исходный код. Программная документация поставляется в электронном и печатном виде. 4.6. Специальные требования:программное обеспечение должно иметь дружественный интерфейс, рассчитанный на пользователя. ввиду объемности проекта задачи предполагается решать поэтапно, при этом модули ПО, созданные в разное время, должны предполагать возможность наращивания системы и быть совместимы друг с другом, поэтому документация на принятое эксплуатационное ПО должна содержать полную информацию, необходимую для работы программистов с ним; язык программирования — C++. 5. Требования к программной документации5.1. Разрабатываемые программные модули должны быть c комментариями по каждому блоку. 5.2. Разрабатываемая программа должна иметь инструкцию о работе программы, описания методов сортировки. 6. Технико-экономические показателиЭффективность системы определяется удобством использования системы для контроля и управления основными параметрами делами нарушителей, а также выгодой, в плане комфортного управления и быстрой оплаты штрафов. 7. Порядок контроля и приемкиПосле передачи Исполнителем отдельного функционального модуля программы Заказчику последний имеет право тестировать модуль в течение 10 дней. После тестирования Заказчик должен принять работу по данному этапу или в письменном виде изложить причину отказа принятия. В случае обоснованного отказа Исполнитель обязуется доработать модуль. 8. Календарный план работ
Приложение AЭтапы планирования разработки приложения - Диаграмма Ганта
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||