Geum.ru

Утверждена приказом ао «казахтелеком»

Вид материалаДокументы
Общие требования
Требования к работам по организации доступа к контент-службам АО «Казахтелеком» по протоколу ipv6
Требования к гарантийному обслуживанию
Таблица соответствия техническим требованиям тендера
Подобный материал:
1   ...   7   8   9   10   11   12   13   14   15

Лот №11. Технические требования к оборудованию и услугам

для внедрения протокола IPv6 (0 этап) на сети ПД АО «Казахтелеком»

  1. Общие требования
    1. Проведение работ должно являться подготовительным этапом (0 этап) в общей стратегии развития протокола IPv6 в сетях ПД АО «Казахтелеком».
    2. Целью проведения работ является подготовка к проведению масштабного тестирования подключения к Сетям передачи данных АО «Казахтелеком» различных типов клиентов с использованием протокола IPv6.
    3. Проведение работ должно включать в себя разработку и внедрение технических решений, обеспечивающих реализацию услуги доступа к IPv6-ресурсам сети Интернет, а также ЦОД и контент-ресурсам МСПД АО «Казахтелеком».
    4. Внедрение системы должно осуществляться на базе существующей IPv4 МСПД АО «Казахтелеком» с внедрением новой системы туннелирования IPv6 трафика с использованием клиентских бесплатных программных продуктов (встроенный клиент MS Windows).
    5. Внедрение системы туннелирования IPv6 должно включать в себя:
      1. Модернизацию существующих устройств, выполняющих функции LAC/LNS – BRAS E-серии;
      2. Осуществление интеграции устройств LAC/LNS с сетью МСПД АО «Казахтелеком»;
      3. Настройку существующих отдельных устройств МСПД для возможности передачи трафика IPv6;
      4. Реализацию тестового подключения клиентов ШПД;
      5. Реализацию тестового подключения корпоративных клиентов;
    6. Устройства LAC/LNS должны использоваться для осуществления терминации клиентских туннелей
    7. Модернизация устройств LAC/LNS должна включать в себя:
      1. Доустановку линейного модуля и сервисного субмодуля;
      2. Реализацию механизмов управления подписчиками:
      3. Автоконфигурирование адресов посредством механизмов SL AAC и/или DHCP v6 IA_NA
      4. Назначение адресов в соответствии с рекомендациями и адресным планом, приведенными в документе «Система адресации IPv6 на сети АО «Казахтелеком».
    8. Модернизация существующих устройств МСПД и региональных сетей должна включать в себя:
      1. Обновление ПО на сетевых устройствах;
      2. Настройку IPv6-маршрутизации;
      3. Организацию стыков с IPv6-апстримами;
      4. Реализацию функционала 6PE.
    9. Предложение об испытании услуг IPv6 должно быть ориентировано на:
      1. Клиентов ШПД;
      2. Бизнес-клиентов



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

Оборудование должно поставляться в составе, указанном в Табл. 1.

№п.п
Оборудование
Кол-во, шт.

г. Алматы

1
Линейный модуль с сервисным субмодулем

1

г. Караганда

2
Линейный модуль с сервисным субмодулем

1

г. Астана

3
Сервисный модуль

1



  1. Технические требования к компонентам маршрутизаторов

Поставляемые компоненты маршрутизатора должны соответствовать следующим требованиям.
    1. Требования к линейным модулям
      1. Поставляемые линейные модули должны:
        1. Выполнять функции обработки трафика;
        2. Взаимодействовать с интерфейсными адаптерами с целью обработки и коммутации трафика от различных сетевых соединений;
        3. Обеспечивать пропускную способность до 3,9Гбит/с;
        4. Иметь возможность выполнять функции резервирования для аналогичного линейного модуля;
    2. Требования к интерфейсным адаптерам

Поставляемые интерфейсный адаптер должен:
      1. Занимать всю высоту линейного модуля;
      2. Быть совместимым с управляющими модулями SRP-320, SRP-120, SRP-100 и шасси маршрутизаторов E120/E320;
      3. Поддерживать следующий функционал:
  • Distance Vector Multicast Routing Protocol (DVMRP) tunnels, also known as IP-in-IP tunnels
  • Generic Routing Protocol (GRE) tunnels
  • L2TP-dedicated tunnel server
  • IP packet reassembly for tunnels
  • MPLS over GRE



  1. Требования к услугам
    1. Требования к составу услуг
      1. Поставщик должен оказать Услуги по модернизации МСПД ДКП АО «Казахтелеком» и сетей Metro Ethernet филиалов ГЦТ «Алматытелеком», ГЦТ «Астанателеком», Карагандинская ОДТ.



    1. Требования к перечню услуг

Предоставляемые услуги должны включать в себя:
      1. Разработку Требований к Местам установки Оборудования;
      2. Предпроектные изыскания на объектах МСПД ДКП АО «Казахтелеком», сетях Metro Ethernet ГЦТ «Алматытелеком», ГЦТ «Астанателеком», Карагандинской ОДТ.
      3. Разработку проектной документации;
      4. Разработку технического проекта.
      5. Разработку Программы тестирования работоспособности и функционала Сети;
      6. Разработку инструкций для абонентов для самостоятельной настройки стека IPv6.
      7. Приемку Мест установки под монтаж оборудования;
      8. Монтаж, пуско-наладку и тестирование оборудования Сети на Местах установки;
      9. Проведение приемочных испытаний Сети.
      10. Проведение обучения 10-ти специалистов Казахтелеком на базе ДАИКТ применяемым IPv6 технологиям.



    1. Требования к местам установки оборудования
      1. Поставщик должен разработать Требования к местам установки Оборудования на основании требований Производителя к условиям окружающей среды и энергопотреблению и данных по тепловыделению.



    1. Требования к предпроектным изысканиям
      1. Предпроектные изыскания должны быть произведены совместно Исполнителем и Заказчиком для оценки следующих параметров:
        1. пригодности зданий и сооружений для монтажа Оборудования;
        2. наличия и местонахождения точек подключения электропитания и заземления;
        3. наличия систем вентиляции и кондиционирования;
        4. расположения проектируемых телекоммуникационных шкафов;
        5. трасс прохождения кабельных коммуникаций.



    1. Требования к проектной документации
      1. Результатом разработки проектной документации должен являться комплект проектных документов, включающий следующие разделы (тома):
        1. Технический проект
        2. Требования к подготовке помещений
        3. Рабочая документация
      2. Рабочая документация должна быть разработана Исполнителем и согласована Заказчиком до начала монтажных работ.



    1. Требования к техническому проекту
      1. Разработка Технического Проекта должна содержать следующие основные разделы:
        1. Описание дизайна Сети;
        2. Структуру проектируемой Сети;
        3. Физическую схему проектируемой Сети;
        4. Логическую схему проектируемой Сети;
        5. Схемы организации узлов Сети;
        6. Систему адресации на Сети;
        7. Система организации маршрутизации на Сети;
        8. Схема организации связи с внешними сетями;
        9. Описание настроек типовых сервисов на Оборудовании.



    1. Требования к программе тестирования работоспособности и функционала сети
      1. Программа тестирования работоспособности и функционала Сети, должна включать:
        1. Перечень и описание тестов для проведения испытаний;
        2. Методику проведения тестов;
        3. Ожидаемые результаты проведения теста;
        4. Протокол проведения тестирования.



    1. Требования к монтажным работам
      1. Работы по Монтажу, Запуску, Наладке и Тестированию Сети должны выполняться Исполнителем на объектах АО «Казахтелеком» с привлечением. соответствующих специалистов Заказчика.
      2. Процесс выполнения работ на каждом объекте должен включать:
        1. Прокладку оптоволоконных кабелей для подключения оборудования Сети к каналам связи (с привлечением ответственного персонала Заказчика), при необходимости, по результатам предпроектного обследования;
        2. Выполнение всех внутришкафных соединений оборудования с подключением его к системам распределения электропитания;
        3. Подключение к каналам связи (с привлечением ответственного персонала Заказчика);
        4. Необходимое конфигурирование оборудования;
        5. Тестирование работоспособности оборудования в соответствии с технологическими инструкциями Заказчика.



    1. Требования к настройке оборудования
      1. Требования к работам по пусконаладке LAC/LNS и интеграции его в МСПД и сети Metro Ethernet
        1. Реализация механизмов управления подписчиками: аутентификация подписчиков с использованием локальной или внешней базы подписчиков
        2. Автоконфигурация адресов подписчиков.
      2. Требования к работам по модернизации МСПД и сетей Metro Ethernet
        1. Реализация подсистемы транспорта трафика протокола IPv6:
        2. Реализация подсистемы транспорта IPv6 в МСПД
        3. Реализация подсистемы транспорта IPv6 в сетях Metro Ethernet: ГЦТ "Алматытелеком", ГЦТ "Астанателеком", Карагандинской ОДТ, а также на сопряжениях МСПД и трех вышеуказанных региональных сетей
        4. Реализация транспорта на сопряжениях с внешними операторами - апстримами и пиринговыми партнерами АО "Казахтелеком"
        5. Реализация подсистемы маршрутизации трафика IPv6
        6. Реализация подсистемы маршрутизации IPv6 в МСПД
      3. Реализация подсистемы маршрутизации IPv6 в Metro Ethernet сетях:
      • ГЦТ "Алматытелеком",
      • ГЦТ "Астанателеком",
      • Карагандинской ОДТ.
    1. Требования к доработке схем организации сервисов
      1. Исполнителем должна быть осуществлена доработка схемы организации сервиса "Услуга доступа в Интернет со статическим IPv4-адресом" для обеспечения возможности предоставления доступа в Интернет по протоколу IPv6 со статическим IPv6-адресом для клиентов, подключаемых МСПД и вышеперечисленных региональных сетей.
    2. Требования к работам по организации доступа к контент-службам АО «Казахтелеком» по протоколу ipv6
      1. Реализация доступа по протоколу IPv6 к контент-службам АО "Казахтелеком" (три контент-службы по согласованию с Заказчиком)
      2. Реализация доступа по протоколу IPv6 к DNS-серверам, ответственным за обработку рекурсивных запросов от пользователей услуги ШПД.
    3. Требования к приёмо-сдаточным испытаниям
      1. Приёмо-сдаточные испытания (ПСИ) должны проводиться после завершения монтажа Оборудования и установки Программного обеспечения на всех Местах установки, в соответствии с Программой тестирования работоспособности и функционала Сети.
      2. Результаты ПСИ должны подтвердить, что Сеть работоспособна и функционирует в полном соответствии с Техническим проектом.
    4. Требования к обучению
      1. Обучение должно проводится для инженерно-технического персонала следующих филиалов: ДКП, ГЦТ «Алматытелеком», ГЦТ «Астанателеком», Карагандинская ОДТ, ДИС в количестве 10 человек (по 2 от каждого филиала)
      2. Поставщик должен предоставить программу обучения по следующему учебному плану:
        1. Введение в протокол IPv6
        2. Обучение настройкам оборудования МСПД, Metro Ethernet сетей.
        3. Обучение настройкам клиентских программных продуктов (встроенный клиент MS Windows).
        4. Поиск и устранение неисправностей при проведении тестирования.



12. Технические требования

к оборудованию и услугам по внедрению системы автоматизации процедур управления сервисами/абонентами GPON доступа. Лот № 12.

  1. Общие требования
    1. Целью выполнения работ по внедрению системы автоматизации процедур управления сервисами и абонентами GPON доступа (Mediator) является:
      1. Разработка модели взаимодействия (системный дизайн) между системой Mediator и смежными системами OSS/BSS, EMS разработка процедур управления сервисами и абонентами GPON доступа, для реализации в ручном или автоматическом режиме;
      2. Разработка и внедрение программно-аппаратного комплекса, выполняющего процедуры управления сервисами и абонентами (Mediator) в автоматическом режиме.
    2. Разработанные Процедуры должны обеспечивать выполнение следующих сервисных процессов:
      1. Активация нового абонента;
      2. Активация сервисов абонента (ID-Net, ID-TV, ID-Phone);
      3. Деактивация существующего абонента (удаление);
      4. Изменение сервисов абонента;
      5. Временная блокировка сервисов абонента;
      6. Изменение данных абонента (замена оборудования, линии).



  1. Требования к работам по разработке модели взаимодействия (системный дизайн)
    1. Системный дизайн проекта должен описывать процедуры по управлению следующими видами сервисов: HSI (ID-Net), IPTV (ID-TV), VoIP (ID-Phone, сервис с терминацией на терминальном абонентском оборудовании (SIP-телефон).
    2. Системный дизайн проекта должен описывать операции, которые необходимо реализовать в системе автоматизации процедур управления Mediator.
    3. Системный дизайн является техническим заданием на внедрение системы автоматизации процедур управления Mediator.
    4. Системный дизайн должен описывать схему взаимодействия между системой Mediator и смежными системами OSS/BSS, EMS.
    5. Системный дизайн должен включать в себя описание последовательности выполнения операций для успешного выполнения каждого из сервисных процессов.
    6. Системный дизайн должен включать в себя описание необходимого набора параметров, которые должны храниться в смежных системах и передаваться в процессе выполнения сервисных операций в систему Mediator для автоматизации процедур управления.
    7. Системный дизайн должен включать в себя описание набора параметров (каталоги вендоров, каталоги экземпляров оборудования и их идентификаторов - Наименование, IP адрес), которые должны храниться в локальной базе системы и являются необходимыми для определения конкретного экземпляра оборудования и корректного формирования команд управления.
    8. Cистемный дизайн должен содержать описание архитектуры системы.
    9. В рамках системного дизайна должен быть разработан протокол взаимодействия между всеми смежными системами.
    10. Протокол взаимодействия должен включать в себя описание и последовательность вызова web-сервисов для корректного выполнения всех сервисных процессов.
    11. Системный дизайн должен лечь в основу для разработки регламентов и инструкций по работе с оборудованием и выполнением сервисных процессов в ручном режиме.



  1. Требования к системе автоматизации выполнения процедур Mediator
    1. Требования к Архитектуре
      1. Система Mediator должна иметь модульную архитектуру.
      2. Система Mediator должна поддерживать возможность реализации распределенной схемы управления оборудованием на сети оператора.
      3. Архитектура построения системы Mediator должна быть централизованной, с инсталляцией основных модулей системы в центральном узле и дальнейшем с возможным выносом отдельных элементов в территориально удалённые точки.
      4. Система Mediator должна иметь в дальнейшем возможность работы в автономном режиме на территориально выделенном узле при потере связи с центральным узлом и автоматическое обновление информации на удалённом узле после восстановления связи.



    1. Требования к функциональным возможностям и характеристикам системы Mediator
      1. Система Mediator должна выполнять процедуры управления сервисами и абонентами (Mediator) в автоматическом режиме в соответствии с разработанной моделью взаимодействия (системным дизайном).
      2. Система Mediator должна иметь пользовательский интерфейс.
      3. Пользовательский интерфейс должен быть реализован на web технологии.
      4. Доступ пользователей к интерфейсам и процессам системы Mediator должен разграничиваться правами и ролями доступа системы.
      5. Все настройки системы Mediator должны храниться в промышленной СУБД.
      6. Система Mediator должна позволять вести каталог типов оборудования (вендоры GPON).
      7. Система Mediator должна позволять вести каталог экземпляров оборудования (EMS серверов).
      8. Система Mediator должна хранить данные по доступу к интерфейсам EMS серверов
      9. Система Mediator должна позволять просматривать список выполненных и ожидающих команд с разными условиями фильтрации.
      10. Система Mediator должна иметь возможность предварительного тестирования правильности выполнения команд.
      11. Система Mediator должна иметь возможность отправить команду на повторное выполнение в случае возникновения ошибки при её первом исполнении.
      12. Система Mediator должна иметь возможность редактирования сформированной команды и возможности отправки модифицированной команды на повторное выполнение. При этом оригинальная команда должна быть сохранена.
      13. Система Mediator должна иметь возможность повторной отправки ошибочно выполненных команд в автоматическом режиме.
      14. Система Mediator должна иметь возможность взаимодействие BSS и коммутационного оборудования при изменении состояния услуг или параметров доступа абонента.
      15. В системе Mediator должен поддерживаться контроль результатов выполнения команд на оборудовании;
      16. В системе Mediator должно производиться логирование действий пользователей;
      17. В системе Mediator должно поддерживаться выполнение массовых управляющих команд по предварительно настроенному расписанию подкорректировать формулировки.
      18. Система Mediator должна хранить дефолтный набор параметров, необходимых для корректного формирования команд, для каждого экземпляра оборудования и для каждой команды. Для каждого типа оборудования система должна хранить свой набор параметров необходимых для корректного выполнения



    1. Требования к Интерфейсам между системами
      1. В системе Mediator должны быть реализованы два типа интерфейсов: для взаимодействия с BSS системой и для взаимодействия с EMS системами управления GPON оборудованием.
      2. Взаимодействие с BSS системой должно обеспечиваться через единый интерфейс.
      3. Взаимодействие с каждой системой управления EMS должно осуществляться через отдельный интерфейс.
      4. Процедуры взаимодействия с BSS должны инициироваться BSS.
      5. Процедуры взаимодействия с EMS должны инициироваться системой Mediator.
      6. Интерфейс взаимодействия с BSS должен быть реализован с помощью веб-сервисов (SOAP).
      7. Интерфейс взаимодействия с EMS должен быть реализован c помощью веб-сервисов (SOAP) или протокола TL1.



    1. Требования к производительности
      1. Система Mediator должна обрабатывать команды, приходящие от внешних систем и передавать на EMS со скоростью не менее 1000 операций в секунду .
      2. В системе Mediator должно быть реализованы четыре интерфейса взаимодействия с EMS (4 вендора GPON) ..



    1. Требования к масштабируемости и развитию функционала.
      1. Система Mediator должна иметь модульную архитектуру и при необходимости должна позволять инсталлировать свои модули на разное серверное оборудование.
      2. Система Mediator должна иметь возможность увеличения количества интерфейсов взаимодействия с EMS.
      3. Система Mediator должна иметь возможность добавления протоколов: telnet, snmp, python, RADIUS, Diameter, COPS-PR,SQL.
      4. Добавление протоколов telnet, snmp, python, COPS-PR,SQL должно осуществляться в рамках предложенной системы  Mediator без замены/дополнения аппаратной конфигурации и без установки дополнительных лицензий.
      5. При добавлении протоколов RADIUS, Diameter возможна замена/дополнение аппаратной конфигурации и установка дополнительных лицензий
      6. Должна быть предусмотрена возможность реализации в дальнейшем интерфейса взаимодействия с внешней базой данных Inventory (например NRI Cramer) посредством протокола SOAP/XML.



    1. Требования к отказоустойчивости
      1. Система должна иметь подсистему диагностики и мониторинга работоспособности используемых процессов.
      2. Возможность работы в автономном режиме на территориально выделенном узле при потере связи с центральным узлом и автоматическое обновление информации на удаленном узле после восстановления связи.
      3. Система должна иметь возможность оповещать (e-mail) администраторов системы о возникновении ошибок при отправке команд на оборудование (EMS сервера).
      4. В случае выхода из строя серверного оборудование, взаимодействие с EMS переводится в ручной режим управления согласно рекомендациям в системном дизайне.



    1. Требования к характеристикам взаимосвязей системы со смежными системами управления
      1. Оборудование должно обеспечивать интеграцию с существующей в АО "Казахтелеком" Системой Управления Сетями Телекоммуникаций посредством передачи потоков аварийных и информационных сообщений с использованием одного из интерфейсов: SNMP, RS-232 / Telnet;
      2. Общие требования ко всем интерфейсам:
        1. Все принимаемые сообщения должны содержать:
        2. Физический и/или логический адрес оборудования, на котором произошла неисправность;
        3. Идентификатор или внутренний номер репортажа;
        4. Тип репортажа (проблема/разрешение/информация);
        5. Категория срочности устранения неисправности (critical/minor/major, и т.п.);
        6. Дата и время возникновения неисправности;
        7. Другая дополнительная информация, которую технический персонал может использовать для локализации и устранения неисправности оборудования.
      3. Эксплуатационная документация на поставляемое оборудование должна содержать перечни аварийных и информационных сообщений, включающие в себя описание формата сообщений, идентификаторы (уникальные ключевые слова) сообщений, и их описание на английском и русском языках.
      4. Требования к интерфейсу SNMP:
        1. Сообщения должны передаваться в следующих форматах:
        2. SNMP V1 traps, V2c traps, and V3 traps;
        3. SNMP V2c and V3 informs.
      5. Эксплуатационная документация на поставляемое оборудование должна содержать:
        1. Версию используемого протокола;
        2. Набор всех необходимых MIB файлов, соответствующий оборудованию, включая все вышестоящие MIB;
        3. Описание Trap’ов и Inform’ов;
        4. Описание и формат значений передаваемых OID’ов.
      6. Требования к интерфейсу RS-232 / Telnet:
        1. Сообщения должны передаваться в формате ASCII или CP1251;
        2. Выводить сообщения без запроса (без выполнения команд);
        3. Сообщение должно заканчиваться фиксированным символом или их набором информируя о логическом завершении сообщения.



  1. Требования к аппаратному обеспечению
    1. Все компоненты Mediator должны инсталлироваться на одном сервере (центральный узел).
    2. Для центрального узла необходимо оборудование:
    • сервер с 1 CPU (2-4 ядра) 2Ghz и выше, минимум 4 ГБ оперативной памяти, минимум 300 ГБ HDD.
    1. Сервер для Mediator должен поставляться в рамках проекта.



  1. Требования к лицензиям и ПО
    1. Система Mediator должна лицензироваться по количеству поставляемых блоков.
    2. Система Mediator должна иметь возможность расширения (установка дополнительных экземпляров блоков) в случае установки ещё одного экземпляра Mediator .
    3. Система Mediator не должна лицензироваться по кол-ву операторских мест.
    4. Система Mediator не должна лицензироваться по кол-ву поддерживаемых вендоров GPON.
    5. Система Mediator не должна лицензироваться по кол-ву одновременно выполняемых команд.
    6. Система Mediator не должна лицензироваться по кол-ву типов выполняемых команд.
    7. Стороннее ПО (сервер приложения, СУБД) должно лицензироваться отдельно.
    8. Все компоненты системы Mediator должны инсталлироваться на ОС платформы Unix.


  1. Требования к срокам и этапам
    1. Проект по внедрению системы должен реализовываться в 2 этапа.
      1. Разработка проекта (системный дизайн). Срок выполнения работ – 30 календарных дней.
      2. Внедрение системы Mediator. Срок выполнения работ – 180 календарных дней.



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



    1. Оказываемые услуги и проводимые работы должны включать в себя:
      1. Предпроектные изыскания (обследование).
      2. Разработка системного дизайна.
      3. Разработку технического задания.
      4. Разработку Программы и методики тестирования работоспособности и функциональности системы.
      5. Инсталляцию и настройку системы на серверах:
        1. Работы по инсталляции, запуску, настройке и тестированию системы выполняются Поставщиком через удалённый доступ к серверам, на которых будет размещена система и EMS серверам.
        2. Процесс выполнения работ включает в себя:
          1. инсталляция системы на сервера.
          2. необходимое конфигурирование системы.
          3. тестирование работоспособности системы в соответствии с технологическими инструкциями Поставщика.
      6. Подготовку представителей Поставщика:
        1. Согласование сроков подготовки пользователей.
        2. Согласование программы подготовки пользователей.
        3. Согласование состава обучающихся пользователей.
      7. Разработка интерфейсов для взаимодействия с EMS для четырёх вендоров GPON
      8. Проведение приёмо-сдаточных испытаний:
        1. После завершения работ по инсталляции и настройки системы, проводятся приёмо-сдаточные испытания, которые должны подтвердить, что инсталлированный комплекс работоспособен и функционирует в полном объёме в соответствии с Техническими требованиями.
        2. В случае, если для проведения приёмо-сдаточных испытаний необходимо дополнительное тестовое Оборудование и Программное обеспечение, оно предоставляется Покупателем.
        3. Приемо-сдаточные испытания проводятся Поставщиком согласно разработанной Поставщиком Программе и методике тестирования работоспособности и функциональности системы с участием представителей Покупателя.



  1. Требования к гарантийному обслуживанию
    1. Поставщик должен иметь возможность предоставить АО «Казахтелеком» следующие услуги по технической поддержке: Для устранения возникающих проблем поставщик обязан предоставить услуги по программе 8 часов в сутки 5 дней в неделю. Услуги по технической поддержке заключаются в полном устранении неисправности и приведении программного обеспечения в состояние, имевшее место до аварии;
    2. Техническая поддержка должна включать в себя, сопровождение программного обеспечения (авторский надзор за поставляемым ПО, устранение ошибок и замечаний в работе ПО, установку новых версий ПО и др.), мониторинг основных процессов ПО;
    3. Услуги по технической поддержке классифицированы по степеням в зависимости от уровня серьёзности проблемы:
      1. Система полностью неработоспособна (ПРОБЛЕМА ПЕРВОЙ СТЕПЕНИ);
      2. Значительная часть функций системы не выполняется, или наблюдается существенное снижение производительности Системы (ПРОБЛЕМА ВТОРОЙ СТЕПЕНИ);
      3. Снижение производительности системы, неработоспособность одной или нескольких функций системы, консультации, настройки системы (ПРОБЛЕМА ТРЕТЬЕЙ СТЕПЕНИ);
      4. Нормативное время на устранение проблем:
      5. проблема первой степени – 4 рабочих часа;
      6. проблема второй степени – 16 рабочих часов;
      7. проблема третьей степени – 5 рабочих дней.
    4. Услуги по технической поддержке должны оказываться на весь период эксплуатации ПО
    5. Услуги по технической поддержке оказываются на основе отдельно заключаемого договора.



  1. Требования к документации
    1. Общие требования:
      1. Вся документация должна быть на русском языке
      2. Вся документация должна соответствовать принятым стандартам. По возможности должны быть использованы стандартизированные символы и термины, рекомендованные МСЭ и МЭК.
    2. Документация должна быть предоставлена в бумажном и электронном видах.



  1. Состав документации
    1. Системный дизайн проекта.
    2. Техническое задание на комплекс выполняемых работ.
    3. Пользовательская документация систему.
    4. Техническая документация на систему.



  1. Для Лотов № 1-12.

Таблица соответствия техническим требованиям тендера