Техническое задание оказание услуг по разработке и внедрению модуля «Управление программой капитального ремонта» Единой Базы Информационных Ресурсов Новосибирской области


Требования к системе 4.1Требования к Системе в целом



Скачать 12.69 Mb.
страница5/14
Дата12.11.2016
Размер12.69 Mb.
Просмотров3429
Скачиваний0
ТипТехническое задание
1   2   3   4   5   6   7   8   9   ...   14

4Требования к системе



4.1Требования к Системе в целом

      1. Требования к структуре и функционированию системы


При реализации настоящего технического задания по разработке и внедрению модуля «Управление программой капитального ремонта» Единой Базы Информационных Ресурсов Новосибирской области, созданная Система должна отвечать следующим требованиям:

  • Система должна иметь централизованную базу данных с предоставлением защищенного доступа для заинтересованных ведомств;

  • в Системе должна быть обеспечена возможность работы в режиме тонкого клиента (работа пользователя осуществляется через веб-браузер), функционирующего в различных операционных средах – Microsoft Windows, Unix (Linux), Mac OS;

  • Система должна быть организована по принципу трехзвенной архитектуры: Web-клиента, сервера приложения и сервера базы данных.

Данные в Системе должны храниться с глубиной не менее 30 лет.
      1. Перечень подсистем, их назначение и основные характеристики


В ходе выполнения работ должны быть разработаны следующие подсистемы Системы:

Таблица 2 – «Подсистемы»




Наименование Подсистемы

Решаемые задачи бизнес-процесса

Подсистема администрирования

Настройка алгоритмов расчетов, создание и редактирование ролей с произвольным набором прав пользователей, создание пользователей, настройка расчетных периодов и процедуры закрытия месяца.

Подсистема справочников и классификаторов

Учет справочников и классификаторов системы. Учет размеров тарифов на капитальный ремонт по домам с возможностью изменения ставки тарифа во времени.

Подсистема взаимодействия с внешними информационными системами

Интеграция с внешними системами, загрузка и выгрузка реестров первичных данных, импорт справочников, online-интеграция.

Подсистема жилищного фонда




Подсистема учета лицевых счетов и начисления

Учет данных собственников жилых помещений МКД -абонентов лицевых счетов

Ведение базы лицевых счетов, регистрации технических параметров и истории изменения абонентов.

Расчет размеров взносов в фонд капитального ремонта, автоматические перерасчеты по изменившимся параметрам, начисление пени.


Подсистема финансового учета

Ведение сальдо по лицевым счетам абонентов, в целом по счету дома, а также по счетам регионального оператора, с возможной аналитической разбивкой по счетам домов. Формирование финансовых документов, учет платежей в сальдо, сторнирование и ликвидация документов.

Подсистема субсидирования

Распределение финансовых лимитов субсидирования МО за счет федеральных средств и средств субъекта РФ в рамках краткосрочных планов капитального ремонта.

Подсистема формирования региональной программы капитального ремонта

Хранение справочников межремонтных сроков эксплуатации, плановых затрат, технического состояния жилого фонда. Автоматическое формирование программы, согласно заданному алгоритму.


Подсистема планирования и проведения капитального ремонта

Планирование перечня услуг и видов работ по каждому МКД, занесение факта и стоимости выполненных работ.

Подсистема жилищный надзор

Учет проверок регионального оператора органами жилищного надзора на предмет соблюдения обязательных требований.

Подсистема аналитики и отчетности

Анализ и отчетность по данным в системе.
      1. Требования к характеристикам взаимосвязей Системы со смежными системами


Для разрабатываемых сервисов в Системе должна быть обеспечена возможность использования открытых форматов данных (XML), с помощью которых можно осуществить обмен информацией со сторонними системами. Форматы обмена данными должны иметь открытую структуру и детальное описание.

В системе должно быть предусмотрена работа интерфейсов взаимодействия как в режиме обмена файлами, так и в синхронном «on-line» режиме.

Так же в Системе должны быть обеспечена возможность загрузки данных в форматах XLS, CSV. Форматы обмена данными должны иметь открытую структуру и детальное описание.

В Системе должно быть обеспечено взаимодействие со следующими системами:



  • ЕБИР;

  • ГИС ЖКХ;

  • «Реформа ЖКХ»;

  • «Банк-Клиент»;

  • Обмен с платежными системами.










        1. Требования к взаимодействию с системой ЕБИР


Предполагаемые рамки взаимодействия с системой ЕБИР:

  • Использование единой авторизации с разрабатываемой Системой и системой ЕБИР;

  • Использование единых справочников и классификаторов;

  • Загрузка информации по характеристикам жилого фонда;

  • Загрузка информации по лицевым счетам.

Использование единой авторизации с разрабатываемой Системой и системой ЕБИР

В рамках использования единой авторизации с разрабатываемой Системой и системой ЕБИР, должно быть обеспечено использование общих логинов и паролей для авторизации пользователей. В Системе допускается использование собственного независимого механизма авторизации, если реализация требований по единой авторизации будет снижать безопасность хранения учетных данных пользователей ЕБИР.
Использование единых справочников и классификаторов.

В рамках использования единых справочников и классификаторов между разрабатываемой Системой и системой ЕБИР должна быть обеспечено использование как минимум следующих единых справочников:



  • КЛАДР (допускается хранение соотношений кодов КЛАДР – ФИАС, при использовании в разрабатываемой системе справочника ФИАС).

  • Материал стен;

  • Вид жилого фонда;

  • Тип юридического лица.

Загрузка информации по характеристикам жилого фонда.

В рамках внедрения Системы необходимо осуществить единовременную загрузку технических характеристик многоквартирного жилого фонда Новосибирской области из системы ЕБИР, с дальнейшей работой с этими данными непосредственно в системе. Выгрузка из системы ЕБИР должна быть предоставлена Исполнителю в формате XML. Описание характеристик, необходимых для загрузки в Систему представлен в таблице 3.

В рамках эксплуатации Системы необходимо реализовать механизм импорта в части периодической загрузки информации технических характеристик многоквартирного жилого фонда Новосибирской области из системы ЕБИР.

При загрузки обновлённых данных в Систему, отличающихся от имеющейся в Системе, не должно происходить изменение данных. Должен формироваться отчет об импорте, в котором указывается какие данные не были загружены.

Таблица №3. Характеристики, необходимых для загрузки в Систему

Параметр

Описание

Адрес




Код КЛАДР или ФИАС




Инвентарный номер здания




Код муниципального образования




Кадастровый номер земельного участка




Серия, тип проекта




Группа капитальности здания




Тип жилого дома

Пример:

- Многоквартирный жилой дом

- Общежитие


Площадь жилых помещений, в т.ч. по видам собственности



Площадь нежилых помещений общего пользования




Количество этажей наибольшее




Количество подъездов




Год постройки




Год проведения реконструкции




Дата приватизации первого жилого помещения




Год проведения последнего капремонта




Вид последнего капремонта




Степень износа здания, в т.ч. по элементам

Элементы:

- внутридомовых инженерных систем электро-, тепло-, газо-, водоснабжения, водоотведения;

- лифтового оборудования, лифтовых шахт

- крыши


- подвальных помещений

- фасада

- фундамента


Наличие установленных коллективных (общедомовых) приборов учета потребления ресурсов

тепловой энергии, горячей и холодной воды, электрической энергии, газа

Материал несущих стен




Вид фасада




Год проведения последнего капитального ремонта фасада




Тип кровли

Примеры:

- Шиферная скатная

- Металлическая скатная

- Иная скатная

- Плоская


Год проведения последнего капитального ремонта кровли




Наличие лифтов




Год проведения последнего капитального ремонта подвальных помещений




Год проведения последнего капитального ремонта мусоропроводов




Количество мусоропроводов




Тип системы отопления

Примеры:

- центральное

- автономное

- поквартирное



- печное

Год проведения последнего капитального ремонта системы отопления




Наличие газа




Год проведения последнего капитального ремонта системы газоснабжения




Год проведения последнего капитального ремонта системы водоснабжения




Год проведения последнего капитального ремонта системы водоотведения




Площадь здания всего




В том числе жилой части здания




Площадь нежилых помещений функционального назначения




Перечень установленных приборов учета




Длина сетей в местах общего пользования

Система электроснабжения

Длина сетей

Система газоснабжения

Количество элеваторных узлов системы отопления

Система теплоснабжения

Длина трубопроводов системы отопления

Система теплоснабжения

Длина трубопроводов системы горячего водоснабжения

Система водоснабжения

Длина трубопроводов системы холодного водоснабжения

Система водоснабжения

Длина трубопроводов системы водоотведения

Система водоотведения

Дата установки, дата проведения последнего капитального ремонта

Лифтовое оборудование

Площадь кровли

Крыша

Площадь обрешетки кровли

Крыша

Тип несущих элементов

Крыша

Площадь подвальных помещений

Подвальное помещение

Площадь фасада

Фасад

Тип фундамента

Фундамент

Объем фундамента

Фундамент

Площадь цоколя

Фундамент

Площадь отмостки

Фундамент

Тип перекрытия

Перекрытия

Площадь междуэтажных

Перекрытия

Площадь подвальных

Перекрытия

Площадь чердачных

Перекрытия

Обмен информацией о лицевых счетах, параметрах жилых помещений и собственников.

В рамках внедрения Системы необходимо осуществить единовременную загрузку информации о собственниках, лицевых счетах из системы ЕБИР, с дальнейшей работой с этими данными непосредственно в системе.

В рамках эксплуатации Системы необходимо реализовать online-интеграцию в части загрузки информации о собственниках, лицевых счетах из системы ЕБИР, с дальнейшей работой с этими данными непосредственно в системе.

Перечень параметров, необходимых для загрузки в Систему:


  • Управляющая компания;

  • ИНН управляющей компании;

  • Адрес абонента;

  • Дом;

  • Квартира;

  • Номер лицевого счета;

  • ФИО абонента;

  • Общая площадь жилого помещения;

  • ФИО собственника жилого помещения.

  • Доля собственности.

При загрузке данных в систему, отличающихся от имеющейся в Системе информации, формируется протокол (отчет) об имеющихся данных и о загружаемых данных, формируется предупреждение для Оператора о загрузке обновленных данных.



        1. Требования к взаимодействию с системой ГИС ЖКХ


Взаимодействие с системой ГИС ЖКХ включает формирование выгрузок данных из Системы в формате реестра данных ГИС ЖКХ, для последующей передачи и загрузки в ГИС ЖКХ.
        1. Требования к взаимодействию с системой «Реформа ЖКХ»


1) В рамках информационного взаимодействия по передаче данных в систему «Реформа ЖКХ» должна быть обеспечена передача информации по видам работ, планируемым к выполнению на МКД входящих в программы капитального ремонта на стадии планирования программы.

2) В рамках информационного взаимодействия по передаче данных в систему «Реформа ЖКХ» должна быть обеспечена передача информации по фактически выполненным видам работ по капитальному ремонту МКД, предусмотренные п.3 ст.15 185-ФЗ.


        1. Обмен с системой «Банк-Клиент»


Обмен с системой «Банк-Клиент» включает получение и загрузку данных в Систему, в режиме офф-лайн, электронных платежных поручений по платежам, осуществленные банком по счетам регионального оператора и спецсчетам многоквартирных домов.

        1. Обмен с платежными системами


В рамках информационного взаимодействия по получению данных из платежных систем должно быть обеспечено получение следующей информации по поступлениям на счет регионального оператора средств абонентов формирующих фонд капитального ремонта:

  • Номер платежного документа;

  • Номер счета абонента;

  • Дата валютирования;

  • Расчетный период (за какой период создается документ);

  • Учетный период (в каком периоде учитывается в сальдо);

  • Вид документа;

  • Сумма по документу.

Формат информационного взаимодействия по получению данных из платежных систем должен быть разработан на этапе технического проектирования Системы.


        1. Требования к взаимодействию с ситуационным с центром Губернатора Новосибирской области или смежным информационным порталом


В рамках информационного взаимодействия с ситуационным центром Губернатора новосибирской области» или смежным информационном портале в Системе должна быть обеспечена передача следующей информации по технологии web – сервисов:


  • Актуальная версия долгосрочной программы капитального ремонта Новосибирской области;

  • Финансовая потребность в капитальном ремонте в разрезе муниципальных образований, типов домов.

  • Актуальная версия краткосрочных программ капитального ремонта Новосибирской области заведенных в системе;

  • Информация по исполнению краткосрочных программ капитального ремонта Новосибирской области, в части агрегированной информации по каждой программе, и информации по каждому жилому дому в краткосрочной программе. Должна передаваться следующая информация:

  • Планируемые объемы выполнения работ;

  • Фактические объемы выполнения работ;

  • Фактически оплаченные работы.

  • Распределение размеров взносов и фондов капитального ремонта по муниципальным образованиям;

  • Фактический уровень собираемости начислений за капитальный ремонта в разрезе муниципальных образований.



        1. Требования к взаимодействию с региональной геоинформационной системой Губернатора Новосибирской области


В рамках информационного взаимодействия с региональной геоинформационной системой Губернатора Новосибирской области должна быть обеспечена передача следующей информации по технологии web – сервисов:


  • Жилые дома заведенные в системе;

  • Состояние жилых домов;

  • Характеристики по жилым домам;

  • Информация о включении жилого дома в долгосрочную и краткосрочную программу капитального ремонта.



      1. Требования к развитию и модернизации Системы


Система должна обеспечивать возможность дальнейшей модернизации, как программного обеспечения, так и комплекса технических средств.
      1. Требования к поддержки версионности


Для получения актуальных данных на любой момент времени в Системе должна быть поддержка версионности параметров объектов, позволяющая извлекать версии объектов, действовавшие в конкретный момент времени для проведения перерасчетов, формирования печатных форм и выполнения других функций за прошедшие периоды.

Версионирование в системе должно использоваться для проведения расчетов по актуальным значениям параметров в заданном периоде, для анализа динамики изменения каких-либо параметров (например, тарифов).

Например, для перерасчета за прошлый месяц, в котором изменился тариф, необходимо знать какой был тариф в прошлом месяце. Таким образом, в Системе для всех параметров, для которых требуется поддержка версионности, необходимо хранить период действия параметра.

Система должна обеспечивать возможность исторического хранения данных с глубиной не менее 30 лет.


      1. Требования к обеспечению защиты персональных данных


В соответствии с п. 1 ст. 19 ФЗ № 152 от 25.07.2007 «О персональных данных», обязанность организации необходимых правовых, организационных и технических мер или обеспечение их принятия для защиты персональных данных от неправомерного или случайного доступа к ним, уничтожения, изменения, блокирования, копирования, предоставления, распространения персональных данных, а также от иных неправомерных действий в отношении персональных данных, возлагается на Заказчика (оператора).

      1. Показатели назначения


Система должна обеспечивать возможность одновременной работы не менее 150-ти пользователей при следующих характеристиках времени отклика системы:

  • для операций навигации по экранным формам системы – не более 2 сек;

  • для операций формирования справок и выписок – не более 1 мин.

Время формирования аналитических отчетов определяется их сложностью и может занимать продолжительное время. При выполнении условий рекомендуемого технического обеспечения, для аналитических отчетов, соответствующих утвержденным отчетным формам проектной документации, за период (1 месяц) - не более 1 часа.

Система должна по возможности обеспечивать линейный рост производительности при росте числа доступных процессоров (серверов).

Система должна обеспечивать функционирование в штатном режиме круглосуточно, без выходных («режим 24*7») с допустимыми регламентными перерывами на техническое обслуживание суммарной длительностью не более 4 часов в месяц и длительностью каждого перерыва не более 1 часа (с полным отключением Системы).


      1. Требования к надежности


Для системы регламентируются показатели надежности при следующих видах аварийных ситуаций:

Общесистемный отказ – выражается в недоступности всех или большинства пользовательских интерфейсов системы вне зависимости от причин, вызвавших этот отказ (отказы средств технического обеспечения, телекоммуникационных средств, общесистемного программного обеспечения, неверная работа специализированных программ, ошибки персонала, сбои электропитания и т.п.), кроме причин катастрофического характера (форс-мажорных обстоятельств).

Частный сбой – выражается в недоступности одного из интерфейсов какой-либо функциональной компоненты или его некорректной работе (отклонении от порядка функционирования, установленного настоящим ТЗ).

Надежность информационного обеспечения Системы должна обеспечиваться совокупностью используемых средств управления базами данных, системы комплексного администрирования и реализацией процессов резервного копирования информационных баз и файлов конфигурации.

После сбоя серверной, клиентской операционных систем или СУБД в процессе выполнения пользовательских задач должно быть обеспечено восстановление данных в базе данных до состояния на момент окончания последней полностью завершенной перед сбоем операции ввода или изменения данных.

При аварийных остановах Системы, не связанных с неисправностью технических средств или повреждением программного обеспечения и данных на долговременных накопителях (жестких дисках и т.п.), восстановление ее работоспособности должно обеспечиваться в срок не более 15 минут.

Максимальное время восстановления работоспособности программного обеспечения Системы при прочих сбоях и отказах не должно превышать 3-х часов. В указанное время не входит устранение неисправностей технического и общесистемного программного обеспечения.

Время восстановления после выхода из строя технического и общесистемного программного обеспечения (с установкой нового оборудования и восстановлением с резервных носителей) < 3 суток. Данный пункт должен быть обеспечен организационными мерами (отдельное хранение резервных носителей, договорённости с поставщиками о поставке оборудования и т.п.).

Система должна обеспечивать удалённое наблюдение за своим состоянием в реальном времени (просмотр логов, сессий, производимых операций и нагрузки на оборудование).

      1. Требования к эргономике и технической эстетике


Взаимодействие пользователей с прикладным программным обеспечением, входящим в состав Системы, должно осуществляться посредством визуального графического интерфейса. Интерфейс Системы должен быть понятным и удобным, не должен быть перегружен графическими элементами и должен обеспечивать быстрое отображение экранных форм. Навигационные элементы должны быть выполнены в удобной для пользователя форме. Ввод-вывод данных в Системе, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс Системы должен соответствовать современным эргономическим требованиям и обеспечивать удобный доступ к основным функциям и операциям Системы.

Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Системой преимущественно должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании полей экранных форм.

Все надписи экранных форм, а также сообщения, выдаваемые пользователю должны быть на русском языке.

Система должна обеспечивать корректную обработку аварийных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях Система должна выдавать пользователю соответствующие сообщения, после чего возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных.

Система должна обеспечивать контроль ввода данных пользователем на предмет заполненности обязательных полей и корректности формата введенных данных.

Экранные формы должны проектироваться с учетом требований по унификации:



  • Все экранные формы пользовательского интерфейса одной подсистемы должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации.

  • Для обозначения сходных операций должны использоваться сходные графические значки, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций (добавление информационной сущности, редактирование поля данных), а также последовательности действий пользователя при их выполнении, должны быть унифицированы.

  • Внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должны реализовываться одинаково для однотипных элементов.

  • При заполнении полей форм по возможности должны использоваться классификаторы и справочники.

  • Для дат должна предусматриваться возможность ввода как в текстовом формате (ДД.ММ.ГГГГ), так и с помощью визуального контрольного элемента – календаря.

  • Все поля ввода и контрольные элементы должны быть снабжены подсказками, всплывающими при наведении «мыши» или вызываемые иным унифицированным способом, и содержащие конкретные указания по назначению элемента интерфейса, содержанию и формату вводимых в поле данных, при необходимости – со ссылками на более детальную информацию.

  • В процессе ввода данных должна осуществляться оперативная проверка их корректности по формату и диапазонам значений. Сообщения об ошибках должны указывать на конкретные отклонения от формата или допустимого диапазона. По возможности должны быть реализованы алгоритмы проверки и подсветки формально допустимых, но «подозрительных» (нетипичных для данного поля) значений (орфографических ошибок и т.п.).

  • При вводе адресной информации в текстовом виде должно обеспечиваться автоматическое распознавание и структурирование адресов с привязкой к определенным в настоящем ТЗ справочникам и классификаторам.
      1. Требования к защите информации от несанкционированного доступа


Доступ к Системе посредством Web-интерфейса должен осуществляться с использованием защищенных протоколов.

Для целей защиты данных сервера БД от несанкционированного доступа конечные пользователи Системы не должны знать пароль доступа непосредственно к самому серверу БД. Авторизация в Системе должна предусматривать доступ к функциям приложения, а не к серверу базы данных.

Требования в части защиты персональных данных от несанкционированного доступа.

Требования защиты от несанкционированного доступа (далее - НСД) обусловлены следующими нормативными правовыми актами:

ст. 19 Федерального закона №152-ФЗ от 27.07.2006 г. (в ред. ФЗ-261 от 25.07.2011г.) «О персональных данных»;

Постановление Правительства РФ от 01.11.2012 № 1119 "Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных".

Защита персональных данных от несанкционированного доступа должна осуществляться использованием следующих факторов:


  • идентификации и аутентификации субъектов доступа и объектов доступа;

  • управления доступом субъектов доступа к объектам доступа;

  • регистрации событий безопасности;

  • обеспечение целостности Системы и информации.

Идентификация и аутентификация субъектов доступа и объектов доступа должна включать:




  • идентификацию и аутентификацию пользователей, процессов, иных субъектов доступа;

  • идентификацию и аутентификацию (в том числе стационарных, мобильных и портативных), объектов файловой системы, запускаемых модулей, объектов систем управления базами данных, объектов, создаваемых прикладным программным обеспечением;

  • управление идентификаторами;

  • управление средствами аутентификации.

Управление доступом субъектов доступа к объектам доступа должна включать:




  • управление учетными записями пользователей;

  • управление предоставлением доступа субъектов доступа к объектам доступа (реализацию различных методов, типов и правил разграничения доступа), в том числе при совместном использовании информации несколькими субъектами доступа;

  • разделение обязанностей различных категорий пользователей (ролей) и администраторов Системы;

  • назначение минимальных прав и привилегий субъектам доступа;

  • оповещение пользователя о доступе к Системе, в которой реализованы меры защиты информации, при его входе в Систему;

  • ограничение числа параллельных сеансов доступа для каждой учетной записи пользователя Системы;

  • блокирование сеанса доступа в Систему после установленного времени бездействия (неактивности) пользователя или по его запросу;

  • установление действий пользователей, разрешенных до идентификации и аутентификации;

Регистрация событий безопасности должна включать:




  • определение событий, относящихся к безопасности персональных данных, и подлежащих регистрации;

  • определение состава и содержания информации о событиях, относящихся к безопасности персональных данных, и подлежащих регистрации;

  • обеспечение возможности просмотра и анализа информации о действиях пользователей;

  • запись (регистрация) информации о событиях, относящихся к безопасности персональных данных;

  • просмотр и анализ результатов регистрации событий, относящихся к безопасности персональных данных, и реагирование на них.

Подсистема обеспечения целостности Системы и информации должна включать:




  • ограничение прав пользователей по вводу информации в информационную систему.



      1. Требования к патентной чистоте


Система и ее части должны обеспечивать патентную чистоту на территории Российской Федерации. Установка системы в целом, как и установка отдельных частей системы не должна предъявлять дополнительных требований к покупке лицензий на программное обеспечение сторонних производителей. На территории Новосибирской области разработанный модуль не имеет ограничений по количеству пользователей, зарегистрированных в Системе. В результате исполнения настоящего технического задания Исполнитель передает Заказчику неисключительное право на разработанный модуль, действующее на территории Новосибирской области.

      1. Требования к гарантийному обслуживанию системы


Срок гарантийного обслуживания составляет 12 месяцев с момента подписания итогового Акта сдачи-приемки оказанных услуг. Случаями, попадающими под условия гарантийного обслуживания Системы, являются:

выявленные несоответствия программной реализации техническому заданию и документации техно-рабочего проекта;

сбои и нарушения в работе Системы, вызванные реализацией программных компонентов Системы;

приведение в соответствие Системы требованиям законодательных и нормативно – правовых актов в течении 12 месяцев.

Исполнитель обязан организовать телефонную «горячую линию» поддержки по вопросам функционирования Системы в рабочие дни в период с 8:30 до 17:30 по местному времени.

      1. Требования по стандартизации и унификации


Система должна обеспечивать поддержку плоской и иерархичной структуры классификаторов и справочников.

Система должна содержать адресный справочник, соответствующий Классификатору Адресов Российской Федерации (КЛАДР) или Федеральной информационной адресной системы (ФИАС).




Каталог: sites -> uksis.nso.ru -> wodby files -> files -> imce -> Obr v MRG2
sites -> Ларцева А. 1 Перевод имен собственных на примере книги ховарда рейнголда
sites -> Памятка для родителей подростков и старших школьников
sites -> Занятие №18 Здравствуйте, участники программ личностного развития для детей!
sites -> Программа кружка «Юный журналист»
sites -> Шелакина А. А. Студентка 2 курса атп 921 ппк сгту имени Гагарина Ю. А
sites -> Культурного и природного наследия имени д. С. Лихачева
sites -> Безопасность детей в образовательных учреждениях России
Obr v MRG2 -> Оглавление сокращения


Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8   9   ...   14


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал