Требования к Системе Требования к Системе в целом
Программно-технологическое расширение функциональных возможностей модулей Системы должно осуществляться на основе функциональных возможностей модулей, разработанных при создании и развитии Системы (первая и вторая очереди). Функциональные возможности модулей должны быть сохранены и расширены под текущие технологические процессы с учетом изменений НПА и усовершенствования внутренних алгоритмов обработки информации.
Требования к структуре и функционированию Системы
Система должна сохранить трехзвенную архитектуру и состоять из следующих компонентов:
данные (уровень хранения данных);
бизнес-логика (уровень приложений);
слой представления, сервисы (презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями).
В соответствии с архитектурой Системы, в состав программного обеспечения должны входить следующие основные компоненты:
сервер базы данных;
сервер приложений;
web-сервер;
клиентские приложения.
Первые три компонента представляют собой покупное, промышленно поддерживаемое программное обеспечение. Специализированные клиентские приложения должны быть разработаны Исполнителем и согласованы с Государственным и Функциональным заказчиками.
Сервер базы данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев.
Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через web-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов).
Web-сервер должен обеспечивать взаимодействие с клиентскими приложениями и внешними информационными системами и ресурсами по HTTP / HTТPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений).
Клиентские приложения должны отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс).
Прикладная схема архитектуры ИСОД МАДИ с учетом расширения функциональных возможностей Системы представлена ниже (Рисунок ).
Рисунок – Прикладная схема архитектуры ИСОД МАДИ с учетом расширения функциональных возможностей Системы
Перечень подсистем, их назначение и основные характеристики
Модули Системы, обеспечивающие деятельность МАДИ:
«Административная практика»;
«Мобильный инспектор МАДИ»;
«Прием и обработка обращений»;
«Мобильное рабочее место руководителя»;
«Аналитическая обработка данных»;
«Планирование и контроль работы сотрудников»;
«Обеспечение информационной безопасности»;
«Нормативно-справочная информация»;
«Взаимодействие с внешними системами»;
«Единая база данных».
Исполнитель должен разработать и согласовать с Государственным заказчиком архитектуру решения, которая должна быть оформлена в соответствии с шаблоном документа «Архитектура Системы» ДИТ города Москвы. Решение по архитектуре должно отвечать, в том числе, нефункциональным требованиям, предъявляемым к Системе.
Требования к модулю «Административная практика»
Модуль «Административная практика» предназначен для решения задач, связанных с автоматизацией подготовки материалов по административным правонарушениям, в том числе зафиксированным средствами автоматической фото-видеофиксации.
Модуль «Административная практика» должен обеспечивать получение через модуль «Взаимодействие с внешними системами» с комплексов фотовидеофиксации из систем АПК МКФ «ПаркРайт» и АПК ПКФ «ПаркНет», а также из модуля «Мобильный инспектор МАДИ» материалов фотофиксации ТС, имеющих признаки нарушений, администрируемых МАДИ.
Детализированные требования к модулю «Административная практика» должны быть уточнены при предварительном проектировании и могут быть скорректированы по согласованию с Государственным и Функциональным Заказчиками.
Требования к модулю «Мобильный инспектор МАДИ»
Модуль «Мобильный инспектор МАДИ» должен позволять инспектору МАДИ, находящемуся на задании (вне подразделения), с помощью средств автоматизации оформлять документы по АПН, производить фотофиксацию ТС и передавать данные в модуль «Административная практика» для дальнейшей обработки.
Модуль «Мобильный инспектор МАДИ» должен обеспечивать авторизацию пользователей и иметь средства криптозащиты от несанкционированного доступа
Детализированные требования к модулю «Мобильный инспектор МАДИ» должны быть уточнены при предварительном проектировании и могут быть скорректированы по согласованию с Государственным заказчиком и Функциональным Заказчиками.
Требования к модулю «Прием и обработка обращений»
Модуль «Прием и обработка обращений» предназначен для решения задач, связанных с автоматизацией учета рассмотрения обращений граждан, направления обращений граждан для рассмотрения в соответствующие подразделения МАДИ, подготовки ответов на обращения граждан.
Детализированные требования к модулю «Прием и обработка обращений» должны быть уточнены при предварительном проектировании и могут быть скорректированы по согласованию с Государственным и Функциональным Заказчиками.
Требования к модулю «Аналитическая обработка данных»
Модуль «Аналитическая обработка данных» предназначен для решения задач, связанных с автоматизацией аккумулирования показателей администрирования правонарушений, а также отображения их в аналитической и статистической отчетности.
Детализированные требования к модулю «Аналитическая обработка данных» должны быть уточнены при предварительном проектировании и могут быть скорректированы по согласованию с Государственным и Функциональным Заказчиками.
Требования к модулю «Планирование и контроль работы сотрудников»
Модуль «Планирование и контроль работы сотрудников» предназначен для решения задач, связанных с автоматизацией процессов назначения заданий сотрудникам, формирования отчетов, осуществления контроля выполнения заданий сотрудниками.
Детализированные требования к модулю «Планирование и контроль работы сотрудников» должны быть уточнены при предварительном проектировании и могут быть скорректированы по согласованию с Государственным и Функциональным Заказчиками.
Требования к модулю «Мобильное рабочее место руководителя»
Модуль «Мобильное рабочее место руководителя» предназначен для решения задач, связанных с автоматизацией предоставления руководству МАДИ интерфейса просмотра информации по аналитическим показателям и показателям эффективности, характеризирующим деятельность подразделений.
Детализированные требования к модулю «Мобильное рабочее место руководителя» должны быть уточнены при предварительном проектировании и могут быть скорректированы по согласованию с Государственным и Функциональным Заказчиками.
Требования к модулю «Обеспечение информационной безопасности»
Модуль «Обеспечение информационной безопасности» предназначен для решения задач, связанных с автоматизацией деятельности по управлению учетными записями пользователей, параметрами идентификации, аутентификации, авторизации и регистрации событий при работе с информацией, обрабатываемой в Системе.
Модуль «Обеспечение информационной безопасности» является частью программного обеспечения Системы и передает сведения о параметрах доступа пользователей в систему информационной безопасности ИСОД МАДИ.
Детализированные требования к модулю «Обеспечение информационной безопасности», в том числе перечень разрабатываемой организационно-распорядительной документации, должны быть уточнены при предварительном проектировании и могут быть скорректированы по согласованию с Государственным и Функциональным Заказчиками.
Требования к модулю «Нормативно-справочная информация»
Модуль «Нормативно-справочная информация» предназначен для решения задач, связанных с автоматизацией процессов консолидации, первичной обработки и ведения нормативно-справочной информации с целью повышения эффективности процессов информационного взаимодействия Системы, а также обеспечения информационного взаимодействия нормативно-справочной информации с внешними информационными системами.
Модуль «Нормативно-справочная информация» должен являться единственным поставщиком нормативно справочной информации для модулей Системы и в полном объеме обеспечивать ведение нормативно-справочной информации, необходимой для функционирования всех модулей Системы.
Детализированные требования к модулю «Нормативно-справочная информация» должны быть уточнены при предварительном проектировании и могут быть скорректированы по согласованию с Государственным и Функциональным Заказчиками.
Требования к модулю «Взаимодействие с внешними системами»
Модуль «Взаимодействие с внешними системами» предназначен для решения задач, связанных с автоматизацией процессов двустороннего взаимодействия с внешними поставщиками первичных данных и потребителями информации, формируемой Системой.
Средства модуля «Взаимодействие с внешними системами», обеспечивающие взаимодействие с различными источниками, должны быть разработаны в едином архитектурном решении и с применением единых технологических подходов к проектированию и реализации. Интеграционные решения модуля «Взаимодействие с внешними системами» должны быть построены преимущественно в соответствии с сервис-ориентированной архитектурой.
Детализированные требования к модулю «Взаимодействие с внешними системами» должны быть уточнены при предварительном проектировании и могут быть скорректированы по согласованию с Государственным и Функциональным Заказчиками.
Требования к модулю «Единая база данных»
Модуль «Единая база данных» предназначен для хранения, предоставления и архивирования информации, используемой модулями Системы.
Модуль «Единая база данных» предназначен для решения задач, связанных с автоматизацией обеспечения взаимосвязи между модулями Системы на основе единого массива информации.
Все модули Системы должны осуществлять свою работу с модулем «Единая база данных» преимущественно напрямую.
Модуль «Единая база данных» должен дорабатываться при соблюдении следующих принципов:
единый стандарт разработки и именования;
обязательное документирование всех объектов БД, находящихся в зоне ответственности:
1.схемы;
2.таблицы;
3.индексы;
4.триггеры;
5.представления;
6.пакеты;
7.хранимые процедуры;
различные модули должны взаимодействовать между собой на уровне БД через проработанные интерфейсы.
Модуль «Единая база данных» должен обеспечивать:
нормализацию данных;
снижение дублирования информации;
возможность масштабирования (масштабируемость) при росте нагрузки и объема хранимых данных;
обработку больших массивов постоянно актуализируемых данных.
Детализированные требования к модулю «Единая база данных» должны быть уточнены при предварительном проектировании и могут быть скорректированы по согласованию с Государственным и Функциональным Заказчиками.
Требования к способам и средствам связи для информационного обмена между компонентами Системы
В качестве протокола взаимодействия между компонентами Системы на транспортно-сетевом уровне необходимо использовать протокол TCP/IP.
Информационное взаимодействие между компонентами Системы осуществляется посредством доступа к модулю «Единая база данных».
Для организации информационного обмена между компонентами Системы должны использоваться специальные протоколы прикладного уровня.
Требования по взаимосвязям Системы с внешними и со смежными системами, обеспечению ее совместимости
В Системе должны быть сохранены существующее информационное взаимодействие со следующими внешними системами для обеспечения деятельности МАДИ:
АИС ЕПП – в части получения рекомендаций по необходимости наложения штрафа за неправильную парковку в Московском парковочном пространстве;
АИС РПР - в части получения сведений о принадлежности собственника ТС к инвалидам;
АС УР – в части обмена информацией по исполнительным производствам с ИС ФССП, получения информации о ТС и их собственниках из ФИС ГИБДД, получения информации о собственниках ТС - юридических лицах из ИС ФНС, синхронизации справочников;
ГИС ЕМП – в части доставки информации о регистрации жалоб и обращений, путем отправки SMS собственникам ТС, предоставившим соответствующие сведения (номер сотового телефона) при подаче жалобы и\или обращения;
ИС РНиП – в части обмена информации о начислениях и их оплате;
ИСС МПГУ – в части предоставления информации о постановлениях по делу об АПН;
СИВ – в части предоставления информацией о постановлениях по делу об АПН и обмена информацией по обращениям;
АПК МКФ «ПаркРайт» – в части получения материалов фотофиксации нарушений;
АПК ПКФ «ПаркНет» – в части получения материалов фотофиксации нарушений;
ГИС ЕПС ПМ – в части доставки информации о регистрации жалоб и обращений, а также решений по жалобам и ответов на обращения;
АИС Таксомотор – в части получения информации по лицензиям на осуществление таксомоторной деятельности;
АИС ЕСОО – в части предоставления сервисов для получения и отсылки информации по обращениям граждан;
ПАК ПМ – в части получения материалов фотофиксации правонарушений.
В Системе должно быть реализовано для обеспечения деятельности МАДИ информационное взаимодействие со следующими внешними системами:
УАИС Бюджетный учет в части обмена данными о начислениях (постановлениях) и о фактах получения средств по оплате штрафов;
ИАС МКОиОБ в части передачи информации о количестве административных правонарушений, количестве и сумме наложенных и оплаченных штрафов за административные правонарушения, администрируемые МАДИ;
АСТУ ОДТИ в части предоставления сервисов получения ссылок на карточку дорожных знаков (объектов дорожно-транспортной инфраструктуры) зарегистрированных в АСТУ ОДТИ;
РНИС в части получения информации по подтверждению присутствия транспортных средств на маршруте (информация по маршрутным ТС);
СУО – в части предоставления сервисов получения информации о деле посетителя по идентификатору с документа, а также предоставления ссылок на открытие дела в ИСОД МАДИ;
ИС Почты России – в части доставки постановлений по делу об АПН, решений по жалобам и ответов на обращения, а также обмена информацией по статусах доставки постановлений, решений по жалобам и ответов на обращения отправителю;
ЕСИА ОД МВД России – в части обмена сведениями и/или журналами аудита о событиях информационного взаимодействия с информационными системами Министерства внутренних дел Российской Федерации;
ИТК МС – в части обмена данными по материалам дел ч.1 ст.20.25 КоАП РФ;
ИАИС ЕГИП – в части получения информации о расположении, площадях и границах зеленых насаждений для модуля «Мобильный инспектор МАДИ».
Информационное взаимодействие с внешними системами должно осуществляться с помощью web-сервисов и форматов данных на основе XML или JSON.
Информационное взаимодействие Системы с внешними системами осуществляется только при наличии технических возможностей по взаимодействию с интегрируемыми системами.
Информационное взаимодействие Системы с внешними системами должно осуществляться при условии, что внешние системы удовлетворяют требованиям по взаимодействию с Системой.
Целесообразность и возможность информационного взаимодействия, а также конечный перечень внешних информационных систем должен быть уточнен на этапе предварительного проектирования Системы.
В случае если взаимодействие с внешними системами не может быть проверено на промышленных (продуктивных) средах взаимодействующих систем (по причине неготовности со стороны внешней информационной системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями настоящего ТЗ, должны быть проверены на тестовом стенде.
Объемы и характер взаимодействия с внешними информационными системами должны быть уточнены при предварительном проектировании Системы.
Требования к режимам функционирования Системы
Функционирование разрабатываемых модулей Системы должно предусматривать три основных режима работы:
штатный режим работы, при котором обеспечивается выполнение задач в объеме функций, предусмотренных настоящим ТЗ;
режим технического обслуживания, необходимый для проведения обслуживания, реконфигурации и пополнения технических и программных средств Системы новыми компонентами;
аварийный режим работы.
Режимы работы предполагают полную или частичную доступность модуля или отдельных функций, выполняемых Системой. Ниже приводится описание режимов функционирования Системы:
штатный режим – основной режим функционирования, когда Система выполняет полный набор требуемых функций с максимальной производительностью. Переход Системы в этот режим должен происходить автоматически при первоначальном запуске Системы в эксплуатацию или по завершении других режимов. Выход из этого режима должен происходить:
в режим технического обслуживания – вручную по команде администратора Системы;
в аварийный режим – автоматически;
режим технического обслуживания – данный режим предполагает полную или частичную остановку работы Системы, с целью выполнения обслуживающим Систему персоналом регламентных операций, направленных на обеспечение технического обслуживания аппаратно-программных средств, обеспечивающих их функционирование. Переход в этот режим должен происходить по команде администратора Системы из штатного или аварийного режима эксплуатации. Выход из этого режима должен происходить автоматически при завершении запланированных операций;
аварийный режим работы – данный режим предполагает полное или частичное ограничение полнофункциональной доступности Системы, явившееся следствием отказа аппаратно-программных средств, обеспечивающих их функционирование. Переход Системы в этот режим должен происходить автоматически. Выход из этого режима должен происходить:
автоматически при устранении причины отказа;
вручную по команде администратора Системы в режим технического обслуживания с целью устранения отказа.
Разрабатываемые модули Системы должны функционировать непрерывно в круглосуточном режиме 365 дней в году. Допускается временное ограничение полнофункциональной доступности отдельных частей модулей Системы:
в периоды выполнения регламентированных работ по обслуживанию аппаратных и программных средств Системы, предусмотренных эксплуатационной документацией;
как результат возникновения внештатных ситуаций, вызванных отказами в работе аппаратных и/или программных средств Системы;
в случае частичной или полной потери работоспособности внешних информационных систем-поставщиков первичной информации для Системы;
во время перехода с одной версии на другую системного или прикладного программного обеспечения Системы.
Требования по диагностированию Системы
Диагностирование Системы должно осуществляться путем анализа записей в системных журналах СУБД и операционной системы, а также с помощью встроенных средств диагностирования программного обеспечения.
Диагностированию подлежат:
сбои и нарушения функционирования технического обеспечения (серверов) Системы;
сбои и нарушения функционирования системного программного обеспечения серверов Системы;
сбои и нарушения функционирования прикладного программного обеспечения серверов Системы;
случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем;
сбои и нарушения функционирования СУБД;
сбои при выполнении регламентных операций резервного копирования.
При возникновении аварийных ситуаций, либо ошибок в программном обеспечении, диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы.
Перспективы развития, модернизации Системы
Технические решения, используемые при проектировании Системы, должны позволять минимизировать трудозатраты по модернизации, требуемые в связи с выпуском новых нормативных актов, приводящих к изменению технологического процесса.
Должна быть предусмотрена возможность масштабирования при увеличении нагрузки на Систему с точки зрения увеличения объемов информации и числа пользователей, последующему расширению функциональных возможностей.
|
