4.2.10 Требования к Подсистеме аналитики и отчетности
В Подсистеме аналитики и отчетности должна быть организована работа следующих АРМ пользователей:
– АРМ администратора;
– АРМ органа исполнительной власти;
– АРМ регионального оператора капитального ремонта;
В Подсистеме аналитики и отчетности должны быть реализованы следующие модули:
– Отчетность;
В рамках модуля Отчетность Система должна позволять осуществлять следующие функции:
1) Возможность формирования выходных документов по установленным шаблонам с использованием продуктов семейства Microsoft Office и OpenOffice (или любой эквивалентный продукт) для формирования выходных документов. Перечень выходных документов приведен в настоящем ТЗ в требованиях к подсистемам. Шаблоны выходных документов должны быть предоставлены Заказчиком на этапе внедрения.
2) Возможность формирования отчетов по установленным шаблонам с использованием продуктов семейства Microsoft Office и OpenOffice (или любой эквивалентный продукт) для формирования выходных документов.
4.2.11 Требования к Подсистеме взаимодействия с внешними информационными системами
Подсистема взаимодействия с внешними информационными системами должна позволять осуществлять следующие функции:
1) Возможность загрузки/выгрузки (интеграции) данных в/из смежных программных систем по технологии web - сервисов. Дополнительно должна быть обеспечена возможность:
информационного обмена по технологии web – сервисов;
использования открытых форматов данных (XML, JSON форматы), с помощью которого можно осуществить обмен информацией со сторонними системами. Форматы обмена данными должны иметь открытую структуру и детальное описание;
реализации выгрузок из базы данных с использование открытого универсального формата. Форматы выгрузки данных должен быть реализованы на базе XML формата.
2) Возможность загрузки данных с помощью импорта. Дополнительно должна быть обеспечена возможность:
импорта данных из текстовых файлов любого стандартизованного формата, разработанного для хранения табличных данных, при условии наличия открытой спецификации на данный формат.
3) Возможность выгрузки данных с помощью экспорта. Дополнительно должна быть обеспечена возможность:
экспорта данных в текстовые файлы форматов: XML, XLS, TXT, CSV.
Подсистема «Взаимодействия с внешними информационными системами» должна как минимум осуществлять взаимодействие со следующими информационными системами:
«Планирование капитального ремонта» - информационная система ГК Фонд содействия реформированию жилищно-коммунального хозяйства;
«Реформа ЖКХ» - информационная система ГК Фонд содействия реформированию жилищно-коммунального хозяйства;
биллинговые системы;
бухгалтерские системы;
сметные системы;
финансовые системы.
4.2.11.1 Взаимодействие с системой «Планирование капитального ремонта»
1) В рамках информационного взаимодействия по получению данных из системы «Планирование капитального ремонта» должно быть обеспечено получение следующей информации в подсистему «Единые справочники и классификаторы»:
виды работ капитального ремонта;
группы конструктивных элементов;
конструктивные элементы;
связь между конструктивными элементами и видами работ по ФЗ №185 ФЗ.
2) В рамках информационного взаимодействия по передаче данных в систему «Планирование капитального ремонта» должна быть обеспечена передача следующей информации:
Из подсистемы «Единые справочники»:
виды работ, добавленные сверх справочника системы «Планирование капитального ремонта»;
группы конструктивных элементов и конструктивные элементы, добавленные сверх справочника системы «Планирование капитального ремонта»;
источники финансирования работ по капитальному ремонту;
связь видов работ, конструктивных элементов и источников финансирования добавленные сверх справочника системы «Планирование капитального ремонта».
Из подсистемы «Единые реестры»:
полный перечень МКД, с характеристиками электронного паспорта;
конструктивные элементы по каждому МКД с нормой стоимости ремонта единицы объема;
виды работ, выполненные по конструктивным элементам.
Из подсистемы «Субсидирование»:
лимиты финансирования капитального ремонта субъектом;
лимиты финансирования капитального ремонта каждым муниципальным образованием субъекта;
Из подсистемы «Финансовый учет»:
планируемые размеры фондов капитального ремонта, каждого МКД, на дату капитального ремонта МКД, формирующего фонд капитального ремонта у регионального оператора;
планируемые размеры фондов капитального ремонта, каждого МКД, на дату капитального ремонта МКД, формирующего фонд капитального ремонта на специальном счете.
3) В рамках информационного взаимодействия по получению данных из системы «Планирование капитального ремонта» должно быть обеспечено получение следующей информации в подсистему «Учет программ и объектов КР»:
черновая версия долгосрочной программы капитального ремонта субъекта, глубиной от 25 до 35 лет, включающая очередь МКД с указанием плановой даты капитального ремонта;
с указанием по каждому МКД предлагаемых видов работ, источников финансирования и лимитов финансирования по источникам в ценах определенного года
черновая версия долгосрочной целевой программы должна позволять формировать очередность МКД в программе в соответствии с критериями очередности, установленными Законом Красноярского края от 27.06.2013 № 4-1451 «Об организации проведения капитального ремонта общего имущества в многоквартирных домах, расположенных на территории Красноярского края», без учета государственной и муниципальной поддержки.
4.2.11.2 Взаимодействие с системой «Реформа ЖКХ»
1) В рамках информационного взаимодействия по передаче данных в систему «Реформа ЖКХ» должна быть обеспечена передача информации по видам работ, планируемым к выполнению на МКД входящих в программы капитального ремонта на стадии планирования программы.
2) В рамках информационного взаимодействия по передаче данных в систему «Реформа ЖКХ» должна быть обеспечена передача информации по фактически выполненным видам работ по капитальному ремонту МКД, предусмотренные п.3 ст.15 185-ФЗ.
4.2.11.3 Взаимодействие с бухгалтерскими системами
В рамках информационного взаимодействия по получению данных из бухгалтерских систем должно быть обеспечено получение следующей информации по поступлениям на счет регионального оператора средств абонентов формирующих фонд капитального ремонта:
№
|
Описание
|
Тип
|
Примечание
|
1.
|
Номер
|
Текстовое
|
|
2.
|
Номер счета абонента
|
Дата
|
|
3.
|
Дата валютирования
|
Текстовое
|
|
4.
|
Расчетный период (за какой период создается документ)
|
Дата
|
|
5.
|
Учетный период (в каком периоде учитывается в сальдо)
|
Дата
|
|
6.
|
Вид документа
|
Справочник
|
Начисление, оплата и т.д.
|
7.
|
Сумма по документу
|
Дробное
|
|
4.2.11.4 Взаимодействие с биллинговыми системами
1) В рамках информационного взаимодействия по получению данных из биллинговых систем должно быть обеспечено получение следующей информации по начислениям и оплате начислений абонентами на формирование фонда капитального ремонта:
№
|
Описание
|
Тип
|
Примечание
|
1.
|
Адрес объекта
|
ФИАС
|
п.4.2.2 настоящего ТЗ
|
2.
|
Управляющая организация
|
Справочное
|
п.4.2.3 настоящего ТЗ
|
3.
|
ИНН управляющей организации
|
Целое
|
|
4.
|
Квартира
|
Справочное
|
п.4.2.3 настоящего ТЗ
|
5.
|
Собственник
|
Справочное
|
п.4.2.3 настоящего ТЗ
|
6.
|
Расчетный месяц начисления
|
Дата
|
|
7.
|
Входящие сальдо начисления
|
Дробное
|
|
8.
|
Сумма начисления
|
Дробное
|
|
9.
|
Сумма перерасчета прошлого периода
|
Дробное
|
|
10.
|
Сумма оплаты в расчетном месяце
|
Дробное
|
|
11.
|
Исходящие сальдо начисления
|
Дробное
|
|
4.2.11.5 Взаимодействие со сметными системами
2) В рамках информационного взаимодействия по получению данных из сметных систем должно быть обеспечено получение следующей информации по сметам работ капитального ремонта каждого МКД:
№
|
Описание
|
Тип
|
Примечание
|
Общая информация по смете:
|
1.
|
Объект капитального ремонта
|
Справочник
|
п.4.2.5 настоящего ТЗ
|
2.
|
Вид работы
|
Справочник
|
п.4.2.2 настоящего ТЗ
|
3.
|
Наименование документы сметы
|
Текстовое
|
|
4.
|
Номер документа сметы
|
Текстовое
|
|
5.
|
Дата документа сметы
|
Дата
|
|
6.
|
Файл документа сметы
|
Файл
|
|
7.
|
Наименование документа ведомости ресурсов
|
Текстовое
|
|
8.
|
Номер документа ведомости ресурсов
|
Текстовое
|
|
9.
|
Дата документа ведомости ресурсов
|
Дата
|
|
10.
|
Файл документа ведомости ресурсов
|
Файл
|
|
11.
|
Наименование сметы
|
Текстовое
|
|
12.
|
Номер сметы
|
Текстовое
|
|
13.
|
Дата сметы
|
Дата
|
|
14.
|
Файл сметы
|
Файл
|
|
15.
|
Итого прямые затраты, руб.
|
Дробное
|
|
16.
|
Накладные расходы, руб.
|
Дробное
|
|
17.
|
Сметная прибыль, руб.
|
Дробное
|
|
18.
|
НДС, руб.
|
Дробное
|
|
19.
|
Другие затраты итого, руб.
|
Дробное
|
|
20.
|
Итого по смете, руб.
|
Дробное
|
|
Данные по каждой позиции сметы:
|
|
21.
|
№ позиции сметы
|
Целое
|
|
22.
|
Обоснование
|
Текстовое
|
|
23.
|
Наименование
|
Текстовое
|
|
24.
|
Единица измерения
|
Текстовое
|
|
25.
|
Количество на единицу
|
Дробное
|
|
26.
|
Количество всего
|
Дробное
|
|
27.
|
Стоимость на единицу
|
Дробное
|
|
28.
|
Общая стоимость
|
Дробное
|
|
29.
|
Основная заработная плата
|
Дробное
|
|
3) В рамках информационного взаимодействия по получению данных из сметных систем должно быть обеспечено получение следующей информации по актам работ капитального ремонта каждого МКД:
№
|
Описание
|
Тип
|
Примечание
|
Общая информация по смете:
|
1.
|
Объект капитального ремонта
|
Справочник
|
п.4.2.5 настоящего ТЗ
|
2.
|
Вид работы
|
Справочник
|
п.4.2.2 настоящего ТЗ
|
3.
|
Номер акта
|
Текстовое
|
|
4.
|
Дата акта
|
Дата
|
|
5.
|
Сумма по акту, руб.
|
Дробное
|
|
Данные по каждой позиции сметы:
|
|
6.
|
№ позиции сметы
|
Целое
|
|
7.
|
Обоснование
|
Текстовое
|
|
8.
|
Наименование
|
Текстовое
|
|
9.
|
Единица измерения
|
Текстовое
|
|
10.
|
Количество на единицу
|
Дробное
|
|
11.
|
Количество всего
|
Дробное
|
|
12.
|
Стоимость на единицу
|
Дробное
|
|
13.
|
Общая стоимость
|
Дробное
|
|
14.
|
Основная заработная плата
|
Дробное
|
|
15.
|
Эксплуатация машин
|
Дробное
|
|
16.
|
Заработная плата механиков
|
Дробное
|
|
17.
|
Материалы
|
Дробное
|
|
18.
|
Трудовые затраты основных рабочих
|
Дробное
|
|
19.
|
Трудовые затраты механиков
|
Дробное
|
|
4.2.11.6 Взаимодействие с финансовыми системами
1) В рамках информационного взаимодействия по получению данных из финансовых систем должно быть обеспечено получение следующей информации по платежным документам оплаты работы по капитальному ремонту каждого МКД:
№
|
Описание
|
Тип
|
Примечание
|
Данные банковской выписки:
|
1.
|
Объект капитального ремонта
|
Справочник
|
п.4.2.5 настоящего ТЗ
|
2.
|
Программа капитального ремонта
|
Справочник
|
п.4.2.5 настоящего ТЗ
|
3.
|
Период
|
Справочник
|
п.4.2.2 настоящего ТЗ
|
4.
|
Бюджетный год
|
Целое
|
5.
|
Входящий остаток
|
Дробное
|
6.
|
Группа финансирования
|
Справочник
|
Программа капитального ремонта
Другие
|
7.
|
Дата выписки
|
Дата
|
|
8.
|
Исходящий остаток
|
Дробное
|
|
9.
|
Лицевой счет
|
Текстовое
|
|
10.
|
Номер выписки
|
Текстовое
|
|
11.
|
Последний день операции по счету
|
Дата
|
|
Данные платежного поручения:
|
|
12.
|
Тип операции
|
Справочник
|
Приход
Расход
|
13.
|
Сумма по документу
|
Дробное
|
|
14.
|
Номер платежного поручения
|
Текстовое
|
|
15.
|
Дата платежного поручения
|
Дата
|
|
16.
|
Номер заявки
|
Текстовое
|
|
17.
|
Дата заявки
|
Дата
|
|
18.
|
Дата операции
|
Дата
|
|
19.
|
Источник финансирования
|
Справочник
|
п.4.2.2 настоящего ТЗ (справочник источников финансирования)
|
20.
|
Плательщик
|
Справочник
|
п.4.2.2 настоящего ТЗ (справочник региональных операторов)
п.4.2.3 настоящего ТЗ под п. 11 (электронный паспорт УО)
|
21.
|
Получатель
|
Справочник
|
п.4.2.3 настоящего ТЗ под п. 12 (электронный паспорт подрядной организации)
|
2) В рамках информационного взаимодействия по получению данных из финансовых систем должно быть обеспечено получение следующей информации о специальном счете и поступлениям на специальные счета открытые в кредитных организациях, за исключением специальных счетов открытых на счете, счетах регионального оператора:
№
|
Описание
|
Тип
|
Примечание
|
Данные по специальному счету
|
1.
|
Адрес объекта
|
ФИАС
|
п.4.2.2 настоящего ТЗ
|
2.
|
Управляющая организация
|
Справочное
|
п.4.2.3 настоящего ТЗ под п. 11 (электронный паспорт УО)
|
3.
|
ИНН управляющей организации
|
Целое
|
|
4.
|
БИК банка
|
Целое
|
|
5.
|
ИНН банка
|
Целое
|
|
6.
|
Корреспондентский счет банка
|
Целое
|
|
7.
|
Специальный счет
|
Целое
|
|
8.
|
Факт открытия специального счета у регионального оператора
|
Логическое
|
|
9.
|
Региональный оператор
|
Справочник
|
п.4.2.2 настоящего ТЗ
|
10.
|
Дата открытия специального счета
|
Дата
|
|
11.
|
Дата закрытия специального счета
|
Дата
|
|
12.
|
Остаток по счету
|
Дробное
|
|
13.
|
Дата актуальности
|
Дата
|
|
Данные по поступлениям на специальные счета:
|
|
14.
|
Адрес объекта
|
ФИАС
|
п.4.2.2 настоящего ТЗ
|
15.
|
Управляющая организация
|
Справочное
|
п.4.2.3 настоящего ТЗ под п. 11 (электронный паспорт УО)
|
16.
|
ИНН управляющей организации
|
Целое
|
|
17.
|
БИК банка
|
Целое
|
|
18.
|
ИНН банка
|
Целое
|
|
19.
|
Корреспондентский счет банка
|
Целое
|
|
20.
|
Специальный счет
|
Целое
|
|
21.
|
Квартира
|
Справочное
|
п.4.2.3 настоящего ТЗ
|
22.
|
Собственник
|
Справочное
|
п.4.2.3 настоящего ТЗ
|
23.
|
Дата взноса
|
Дата
|
|
24.
|
Сумма взноса
|
Дробное
|
|
4.3 Требования к видам обеспечения
4.3.1 Требования к информационному обеспечению системы
Система должна обеспечивать хранение информации об информационных объектах указанных в п. 4.2 настоящего ТЗ.
Вся необходимая информация, которая поддается классификации, должна быть организована в классификаторы и справочники.
В Системе должна контролироваться корректность вводимой информации, а также проверяться логическую целостность информации в базе данных при выполнении любой прикладной операции;
При наличии требований к формированию в рамках реализуемых по настоящему ТЗ функций Системы юридически значимых документов на бумажном носителе, придание юридического значения электронным документам, должно осуществляться путем использования соответствующих типу документа средств электронной цифровой подписи в соответствии с требованиями Федерального закона Российской Федерации от 6 апреля 2011 г. N 63-ФЗ «Об электронной подписи».
4.3.2 Требования к программному обеспечению системы
Серверные части всех сервисов должны быть рассчитаны на кросс-платформенное использование. Их корректное функционирование должно быть проверено в средах операционных систем семейств Microsoft Windows Server, Linux 32- и 64-разрядных архитектур. Конкретные версии операционных систем должны быть определены Исполнителем по согласованию с Заказчиком на стадии внедрения.
Системы управления базами данных всех подсистем должны обеспечивать транзакционные механизмы, обеспечивать декларативную ссылочную целостность, позволять наращивать производительность путем увеличения вычислительной мощности без изменений на прикладном уровне. Версия СУБД должна быть определена Исполнителем по согласованию с Заказчиком на стадии проектирования.
АРМ Системы должны быть рассчитаны на использование браузеров с поддержкой HTML 4.0, CSS Level 2, JavaScript 1.1. и выше, режима асинхронного взаимодействия JavaScript/XML (XMLHttpRequest и т.п.). Как минимум, пользовательские интерфейсы должны быть протестированы на совместимость с браузерами Microsoft Internet Explorer версии 8.0 или выше, Mozilla FireFox версии 6.0 или выше, Google Chrome версии 10.0 или выше.
Программное обеспечение должно быть разработано с возможностью установки на ОС семейства Linux, в частности CentOS 6.
Требования к режимам функционирования Системы
Система должна поддерживать следующие режимы функционирования:
штатный режим функционирования;
профилактический режим функционирования;
аварийный режим функционирования.
Штатный режим функционирования является основным при эксплуатации Системы. В данном режиме Система должна обеспечивать выполнение всех заявленных функций и обеспечивать работу зарегистрированных пользователей в соответствии с показателями назначения.
В профилактическом режиме функциональные возможности для пользователей недоступны. При этом допускается проводить профилактические работы для компонентов в отдельности.
Аварийный режим функционирования Системы характеризуется отказом одного или нескольких компонентов программного и (или) аппаратного обеспечения. В этом режиме должны приниматься меры к обеспечению временной работоспособности Системы (возможно с ограничением в выполнении отдельных функций), после чего производится анализ причин выхода Системы в аварийный режим, и проводятся мероприятия по восстановлению полной работоспособности.
В Системе должен быть реализован автоматический контроль нормального состояния ее функционирования, задействованы функции отслеживания и фиксации нештатных и аварийных ситуаций, созданы механизмы обеспечивающие возможность восстановления работоспособности после отказов, сбоев или аварий.
Требования к диагностированию Системы
Требования не предъявляются.
Перспективы развития, модернизации Системы
Система должна предоставляться с учётом перспектив развития, модернизации и масштабирования. Развитие и модернизация Системы должны предусматриваться в следующих направлениях:
повышение технических характеристик, таких как производительность серверов и рабочих станций, пропускная способность каналов связи;
расширение перечня объектов и субъектов ЖКХ, подлежащих мониторингу и управлению;
модернизация программного обеспечения, наращивание и изменение функционала;
добавление новых автоматизированных рабочих мест.
Компоненты Системы должны допускать модернизацию, связанную с изменением технического обеспечения, операционного окружения, применением новых современных интерфейсных средств, методов и протоколов связи и информационного обмена.
Требования к квалификации персонала Системы
Для администрирования Системы необходимы базовые знания по настройке web-сервера и сервера базы данных. При этом администратор Системы не должен быть специалистом в настройке и администрировании этих серверов, т.е. Система должна быть разработана таким образом, чтобы процедуры развертывания ИАС УПКРКК, установки обновлений, резервного копирования были реализованы с максимальным удобством и не требовали специальных знаний от технического специалиста.
Интерфейс Системы должен быть построен таким образом, чтобы пользователю, знакомому с интерфейсом операционной системы Microsoft Windows, было просто разобраться с элементами интерфейса. Общая концепция интерфейса должна быть организована таким образом, чтобы обеспечить комфортную работу пользователей и интуитивно понятное взаимодействие с Системой.
Показатели назначения Системы
Система должна обеспечивать возможность одновременной работы не менее 200 пользователей при следующих характеристиках времени отклика системы:
для операций навигации по экранным формам системы – не более 2 сек;
для операций формирования справок и выписок – не более 1 мин.
Время формирования аналитических отчетов определяется их сложностью и может занимать продолжительное время. При выполнении условий рекомендуемого технического обеспечения, для аналитических отчетов, соответствующих утвержденным отчетным формам проектной документации, за период (1 месяц) - не более 1 часа.
Система должна по возможности обеспечивать линейный рост производительности при росте числа доступных процессоров (серверов).
Система должна обеспечивать функционирование в штатном режиме круглосуточно, без выходных («режим 24*7») с допустимыми регламентными перерывами на техническое обслуживание суммарной длительностью не более 4 часов в месяц и длительностью каждого перерыва не более 1 часа (с полным отключением Системы).
Требования к надежности Системы
Надежность Системы должна обеспечиваться разработкой и реализацией организационных и технических мероприятий, направленных на выполнение заданных в данном техническом задании требований к надежности.
Система является распределенной системой и ее надежность должна определяться надежностью ее составных частей и элементов.
Надежность Системы в целом и каждой ее автоматизированной функции должна быть достаточной для достижения установленных целей функционирования системы при заданных условиях применения.
Технические средства Системы по показателям надёжности должны соответствовать требованиям ГОСТ 27883-88.
В Системе должны быть предусмотрены меры защиты:
от неправильных действий персонала;
от внезапных отключений напряжения питания аппаратуры;
от помех и искажений при передаче информации;
от влияния отклонений температурных параметров, влажности, электромагнитных полей по условиям работы аппаратуры;
от случайных изменений и разрушения информации и программ;
от несанкционированного вмешательства.
В качестве показателей надежности программного обеспечения Системы следует использовать интенсивность перезапусков (перезагрузок) и их длительность. Оценку значений интенсивности и длительности перезапусков (перезагрузок) программного обеспечения следует производить по результатам наблюдения за работой Системы в ходе опытной эксплуатации.
|
