Приложение №1. RFI Транспорт. Версия 2

Запрос информации на поставку модулей управления рабочим временем транспорта в ОАО
«МОСКОВСКАЯ ГОРОДСКАЯ ТЕЛЕФОННАЯ СЕТЬ»
ЗАПРОС ИНФОРМАЦИИ НА ПОСТАВКУ МОДУЛЕЙ УПРАВЛЕНИЯ РАБОЧИМ
ВРЕМЕНЕМ ТРНАСПОРТА В ОАО «МОСКОВСКАЯ ГОРОДСКАЯ
ТЕЛЕФОННАЯ СЕТЬ»
г. Москва
2015
5/5/2016
Стр. 1 из 13
Запрос информации на поставку модулей управления рабочим временем транспорта в ОАО
«МОСКОВСКАЯ ГОРОДСКАЯ ТЕЛЕФОННАЯ СЕТЬ»
Содержание документа
1.
Введение ................................................................................................ 3
1.1.
1.2.
2.
Назначение документа......................................................................... 3
Термины и определения ...................................................................... 3
Функциональные требования ............................................................ 5
2.1.
2.2.
Этапы работ ......................................................................................... 5
Функциональные требования .............................................................. 6
2.2.1.
2.2.2.
2.2.3.
2.2.4.
2.2.5.
2.2.1.
2.2.2.
2.2.3.
2.2.4.
3.
Нефункциональные требования ..................................................... 10
3.1.
3.2.
3.3.
3.4.
3.5.
3.6.
3.7.
3.8.
5/5/2016
Базовые принципы ..................................................................................... 6
Общие требования .................................................................................... 6
Требования к модулю администратора системы .................................... 6
Требования к справочникам ..................................................................... 7
Требования к модулю «Диспетчер» ......................................................... 7
Требования к мобильному приложению .................................................. 8
Требования к модулю «Контроль» ........................................................... 8
Требования к модулю «Статистика» ........................................................ 8
Интеграция с внешними системами ......................................................... 9
Ограничения ....................................................................................... 10
Требования к производительности ................................................... 10
Требования к доступности и надежности.......................................... 10
Требования к логированию ................................................................ 10
Требования к мониторингу и контролю показателей качества ........ 11
Требования к времени хранения данных и архивации .................... 12
Требования к информационной безопасности ................................. 13
Требования к пользовательскому интерфейсу системы ................. 13
Стр. 2 из 13
1.
ВВЕДЕНИЕ
1.1.
Назначение документа
В данном документе содержится описание технических, функциональных и
интеграционных требований к модулям управления рабочим временем транспорта
ОАО «Московская Городская Телефонная Сеть».
1.2.
Термины и определения
В этом разделе приводится список основных понятий и сокращений, используемых
в настоящем документе.
Понятие
Определение
Провайдер
Поставщик услуг фиксированной связи
Вендор
Производитель программного обеспечения (Модулей управления рабочим временем
транспорта)
ТС
Транспортные средства
ОУ
Оконечное устройство
Дежурное ТС
Служебный автомобиль, находящийся в собственности Общества, либо
предоставляемый Обществу сторонней транспортной компанией по договору
аутсорсинга:
1.Легковой (грузовой, микроавтобус) автомобиль с водителем, работающий в
круглосуточном режиме, предназначенный для обеспечения ликвидации аварий и
аварийных ситуаций на объектах связи ОАО МГТС. Выделяется в подразделения ТБ
на основании служебных записок ЧП-ЗГД-ТД, согласованных с ДУИАВ (ЗДУИАВ), с
установленной длительностью работы (смены) данного подразделения 24 часа в сутки,
либо 12 часов в сутки при работе в дневное и ночное время, либо 12 часов в сутки при
работе в дневное и вечернее время.
2.Специальный автомобиль (ЦТО) с водителем, входящий в состав дежурной группы
автомобилей ЦТО, находящийся в режиме круглосуточного дежурства на: АБЦТО и
АВС Цеха КООС ДЭЛС ТБ. Автомобили данной группы выезжают на устранение аварий
на объектах Общества только по заявке дежурного сотрудника (диспетчера) ОКиО
ЦМиК ДТС. Регистрация данных заявок в ЦТО производится в отдельном журнале
Это - мобильный терминал, предназначенный для определения местоположения
автотранспортных средств с помощью GPS\ГЛОНАСС систем позиционирования с
высокой точностью и минимальным временем отклика и обеспечивающий:
Навигационное
оборудование
- контроль движения автотранспортных средств;
- отображение маршрутов их следования в информационных системах мониторинга;
- оповещение о срабатывании подключённых датчиков
Парковочная карта
Пластиковая карта, установленного номинала, предназначенная для оплаты парковки
в терминалах оплаты (паркоматах) г. Москвы
Понятие
Определение
Персональный
водитель
Штатный водитель легкового автомобиля ЦТО, за которым закреплен персональный
автомобиль
Служебный
автомобиль
Все автомобили, используемые в Обществе, оплата расходов по которым
осуществляется за счет средств бюджета Общества. К ним относятся: персональные,
разъездные, специальные и дежурные автомобили.
Специальный
автомобиль
Служебный автомобиль, находящийся в собственности Общества, на шасси которого
смонтировано спец. оборудование (автокран, автовышка, компрессор,
гидроманипулятор, водооткачивающее оборудование, парогенератор, погружные
водооткачивающие насосы и т.д.), эксплуатация которого происходит под
управлением штатного водителя ЦТО, имеющего соответствующее удостоверение
Ростехнадзора (Учебного Центра) и допуск к самостоятельному управлению данным
спец. оборудованием (допуск водителей к работе на автомобилях со спец.
оборудованием, подконтрольных Ростехнадзору, осуществляется на основании
приказа по Обществу).
eADDR
Единая адресная база
ЦТО
Центр транспортного обеспечения
2.
ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
2.1.
Этапы работ
1. Аналитическая фаза. Все проектные документы должны быть на русском языке.
Аналитическая фаза включает в себя:
a. Разработку схем модулей системы.
b. Разработку технических требований к смежным системам (интегрируемым
системам).
c. Разработку технического задания решения на внедрение модулей.
d. Разработку технического задания на интеграцию систем в составе функциональной
архитектуры.
e. Формирование технических требований к мониторингу решения и интегрируемых
модулей; требований производительности и надежности решения.
f. Разработку единой программы приемо-сдаточных испытаний.
g. Разработку руководств пользователя (включая техническое описание решения) и
администратора решения.
h. Формирование требований к спецификации комплекса технических средств
решения.
2. Разработка и поставка решения.
a. Разработка и адаптация решения согласно проектной документации.
b. Сборка и тестирование решение на стороне поставщика. По результатам
предоставление протокола тестирования и методики тестирования.
3. Приемо-сдаточные испытания.
a. Автономные приемки на ТС Провайдера.
b. Интеграционные приемки на ТС Провайдера.
c. Сквозные приемки.
4. Внедрение решение
5. Опытная эксплуатация
a. обучение персонала
b. соответствие
результатов
интеграции
взаиморасчетов с операторами
с
существующими
c. устранение недочетов, выявленных вследствие опытной эксплуатации
d. переключение взаиморасчета на целевое решение.
6. Коммерческая эксплуатация
решениями
Функциональные требования
2.2.
2.2.1.
Базовые принципы
Для автоматизации процессами управления рабочим временем транспорта МГТС, система
должна обеспечивать следующие функции:












Взаимодействие с автоколоннами ЦТО и сторонними транспортными компаниями по
транспортному обеспечению подразделений
Планирование, контроль выделения и использования автотранспорта
Учёт расходования средств на транспортное обеспечение
Регистрация заказов на выезд транспорта
Возможность отслеживания перемещения машин к требуемому месту
Возможность расчёта оптимальных маршрутов передвижения автомашин с учётом
загруженности дорог и пробок
Возможность настраивать функции системы с помощью рабочего места администратора
(Внешний вид рабочих мест диспетчера, карточки заказа, распределения заказов,
Настраиваемые условия распределения машины в очереди и при отказе от заказа, график
работы водителей и диспетчеров и т.д.)
Возможность построить Отчёты и собрать статистику по требуемой информации
В системе должна быть возможность настроить видимость функциональных модулей по
ролям
Система должна быть интегрирована с внешней ИС , для создание заказов на выезд ТС из
внешних систем
Система должна быть интегрирована с мобильным приложением , для работы с заказами
водителями удалённо
Система должна быть интегрирована с Навигационным оборудованием для определения
местоположения автотранспортных средств с помощью GPS\ГЛОНАСС
2.2.2.
Общие требования
1. В системе необходимо реализовать модули
 «Администрирование» для управления настройками системы (Наполнение
справочников, создание пользователей, занесение информации по ТС и т.д)
 «Диспетчер» для управления заказами на ТС
 «Контроль» для управления жалобами и уведомлениями
 «Статистика» для формирования отчётов
2.2.3.
Требования к модулю администратора системы
2. В модуле «Администратора» должна быть возможность настроек тарифных планов и
типов заказов, с которыми работает организация.
3.
В модуле «Администратора» должна быть возможность управлять пользователями
системы. (Редактирование, создание нового пользователя, добавление пользователя в
определённые группы и т.д.)
4. В модуле «Администратора» должна быть возможность работать со справочниками.
(Наполнение изменение справочников)
Требования к справочникам
2.2.4.
5. В системе должны вестись справочники, с возможностью их наполнения и
редактирования:
 Справочники заказчиков
 Справочник водителей:

В справочнике должна быть возможность просмотра с учётом заданных
фильтров карточки водителя (рабочих смен водителя, список заказов
водителя, возможность просмотра маршрутов водителей и т.д)

Должна быть возможность закрепления ТС за определённым водителем
 Справочник ТС с возможностью описания параметров ТС и с последующим
просмотром карточки ТС (Модель ТС, Тип ТС(Аренда, собственный автопарк и
т.д), год выпуска, доступные тарифы и т.д)
 Справочник Юр.лиц которым принадлежат транспортные средства с
возможностью просмотра карточки каждого Юр.лица
 Справочник тарифов для арендуемых автомобилей
2.2.5.
Требования к модулю «Диспетчер»
6. В модуле «Диспетчер» должна быть возможность создания нового заказа на ТС.
7. При оформлении заказ должна быть возможность указать:

Кол-во транспортных средств в заказе

Время подачи ТС

Контактные данные для связи водителя с заказчиком

Указать адресные элементы места подачи машины

Способ оплаты
И т.д.
8. Должна быть возможность на основании предварительно сформированных графиков
месячного планирования сформировать заказ на несколько транспортных средств, с
указанием периода использования ТС.
9. Должна быть возможность отправить SMS-оповещение заказчику ТС о назначении
машины.
10. Должна быть возможность в заказе выбрать тип ТС (Аренда, ТС собственного автопарка,
специальное ТС и т.д) с последующим выбором машины в зависимости от выбранного
типа ТС.
11. При формировании заказа должна быть возможность выбрать ТС которое находится в
ближайшем радиусе от адреса подачи, с возможностью определения километража радиуса
с учётом пробок.
12. После формирования маршрута в заказе должна быть возможность просмотреть маршрут
на карте.
13. Поле формирования заказа сформированный заказ должен автоматически поступать на
мобильное устройство водителю с указанием необходимых параметров для
осуществления выполнения заказа водителем.
14. После формирования заказа, сформированный заказ должен отображаться в общем списке
отображения сформированных заказов.
15. В модуле «Диспетчер» должна отображаться информация:
 По водителям на смене
 По текущим заказам, в том числе по заказам со статусом «В пути»
16.
17.
18.
19.
20.
21.
22.
 Информация по ходу процесса по каждому выбранному заказу
 Из модуля «Диспетчер» должна быть возможность осуществить вызов на
требуемый номер
 Список текущих заказов
Из списка сформированных заказов должна быть возможность перейти в карточку, для
просмотра подробной информации по заказу.
При просмотре списка сформированных заказов должна быть возможность просмотреть
заказы, используя фильтрацию по заданным параметрам. (По дате, типу заказов,
просмотреть все заказы выбрав конкретного заказчика и т.д)
В модуле «Диспетчер» должна быть возможность настроить отображение информации по
сформированным заказам.
В модуле «Диспетчер» должна быть возможность информацию по сформированным
заказам импортировать в другой формат.
В модуле «Диспетчер» должна быть возможность работать со сменами водителей.
(Назначить смену для требуемого водителя, фиксация рабочего времени водителя и т.д)
Должна быть возможность осуществить контроль\просмотреть статистику по
местонахождению машин с просмотром местонахождения машины на карте.
В модуле «Диспетчер» должен быть реализован интерфейс передачи сообщений для
обмена с сообщениями между участниками процесса.
Требования к мобильному приложению
2.2.1.
23. В приложении на мобильном устройстве водителя должна быть возможность управления
заказами.
24. Должна быть возможность в определённый момент времени отказаться от заказа, при этом
при отказе в модуле диспетчера напротив данного заказа должно выводиться оповещение о
необходимости о переназначении заказа.
25. Все действия с назначенным заказом в приложении на мобильном устройстве водителя
должны транслироваться в сформированный заказ в модуль «Диспетчер». («Отмена»,
«Взят в работу» и т.д.)
Требования к модулю «Контроль»
2.2.2.
26. В модуле «Контроль» должна быть возможность заносить информацию по качеству
выполненного заказа.
27. В модуле «Контроль» должна быть возможность сделать рассылку информационных
сообщений, как определённому лицу, так и списку лиц.
Требования к модулю «Статистика»
2.2.3.
28. Должна быть возможность построить отчёты с возможностью указания входных
параметров для построения отчёта и с применением фильтрации:
 По заказам
 По водителям
 По организациям у которых было арендовано ТС
 По ТС, с возможность просмотра информации по задействованию ТС
И т.д
29. На основании задействованных ТС должна быть возможность сформировать отчёт по
планированию транспортного обеспечения на периоды (год, месяц).
30. Для отчётов по арендованным ТС в отчётах должна быть отображена стоимость заказа.
31. Должна быть возможность вывода на печать результата построения отчёта.
32. Должна быть возможность импорта отчёта в другие форматы.
2.2.4.
Интеграция с внешними системами
Система управления ТС должна быть интегрирована с внешними системами.
33. Из внешних систем должна быть возможность оформить заявку на заказ ТС, с указанием
параметров необходимых для формирования заявки на выезд ТС (Время задействования
ТС, адреса подачи ТС, , вида ТС и т.д.)
34. Должна быть осуществлена интеграция с системами транспортных компаний у которых
будет осуществляться аренда ТС, для формирования заказов на арендуемые ТС.
35. Должна быть обеспеченна интеграция с IP телефонией для осуществления вызов на ОУ из
интерфейса системы.
36. Должен быть реализован программный интерфейс, который позволит обмениваться
сообщениями между участниками процесса. (Message Passing Interface)
37. Система должна быть интегрирована с ИС eADDR .
3.
НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
3.1.
Ограничения
1. В данном документе не рассматриваются процессы доработки необходимые для
учёта процесса по предоставлению дежурных ТС.
3.2.
Требования к производительности
2. IT-сервис на текущем КТС должен корректно работать при единовременном
количестве запросов:

общее кол-во запросов - не более 100 000 в день (6000 в час, 200 в минуту),
3. Решение не должно иметь программно-архитектурных ограничений по
производительности: максимальная нагрузка может быть увеличена путем
горизонтальной масштабируемости (увеличения ресурсов КТС). Методика расчета
максимальной нагрузки (количества запросов в единицу времени/ количества
активных пользователей) должна передаваться вместе с решением по результатам
нагрузочного тестирования.
4. Время обработки пользовательского запроса не должно превышать 5 минут для
100% от общего числа запросов.
3.3.
Требования к доступности и надежности
1. Требуется обеспечить возможность работы IT-сервиса в режиме 365(366)х24х7.
2. Максимальное допустимое время простоя IT-сервиса не должно превышать 175
часов в год в год (надежность уровня 98).
3. Время восстановления доступности IT-сервиса в случае сбоя не должно превышать
4 часов.
4. При выходе из строя ПО не должно оказывать влияние на работу не связанных с
ним бизнес-логикой IT-сервисов.
5. Действия пользователей
«зависанию» ПО.
не
должны
приводить
к
потере
информации,
6. В случае временной недоступности программных систем/подсистем и/или сбоев
на сети, корректная работа IT-сервиса должна восстанавливаться по факту
устранения «внешней» неполадки.
7. Система должна работать стабильно и быть устойчивой к различным видам сбоев,
в том числе аппаратных и сбоев операционной системы.
8. Система должна обладать средствами создания резервных копий,
обеспечивающими возможность полного восстановления данных при аварийных
сбоях.
3.4.
Требования к логированию
1. Механизм протоколирования сбоев/ ошибок в работе IT-сервиса не должен
вносить задержек в работу бизнес-процессов.
2. Необходимо обеспечить логирование потоков данных (выгрузка в текстовый файл):
как входящих запросов, так и исходящих. Должны логироваться успешные и
неуспешные попытки аутентификации пользователя, а также попытки доступа
пользователя к данным /ресурсам ИС. Лог-запись должна содержать:

дату и время (timestamp) события;

идентификатор пользователя;

источник события (IP-адрес /идентификатор вызывающей подсистемы);

название или тип операции/выполненного события;

значения параметров запросов/ответов;

результат обработки.
3. ПО должно обеспечивать обнаружение и диагностику ошибок с выдачей
соответствующих сообщений администратору через лог-запись, недвусмысленно
характеризующую причину сбоя. В лог должна попасть информация о всем пути
выполнения операции на данной ИС, приведшем к сбою, без необходимости
включать другой уровень логирования и ловить ошибку заново.
4. Система должна производить уведомление администраторов обо всех фактах
сбоев в том числе в интерактивном режиме.
5. Для использующих БД решений реализовать на содержащей соответствующую
логику схеме БД логирование в таблицу СУБД фактов вызова и результатов работы
хранимых процедур. При этом лог-записи должны содержать только данные,
принятые в запросе (параметры хранимых процедур), и данные, передаваемые в
ответе (значения выходных параметров, а также возвращаемые наборы данных
(записи курсоров)).
6. Предусмотреть возможность изменения параметров логирования в режиме
онлайн (без рестарта сервисов бизнес-логики).
7. Сервисы бизнес-логики могут удерживать файлы логов только в момент записи в
них какой-либо информации, в остальных случаях файлы логов должны быть
свободны для перемещения/удаления. Необходимо реализовать механизм
ротации файлов логирования с присвоением даты/времени к названию файла,
ротация должна организовываться по достижению определенного объема файла
или периода времени.
3.5.
Требования к мониторингу и контролю показателей
качества
1. Должны быть выделены и зафиксированы в предлагаемой реализации ТЗ
(документ «Архитектура решения», HLA и т.п.) измеряемые комплексные
верхнеуровневые
КПЭ
здоровья
решения,
определяющие
уровень
предоставляемого сервиса.
2. Решение должно обеспечивать возможность измерения КПЭ IT-сервиса. Методика
расчета КПЭ должна быть представлена в предлагаемой реализации ТЗ (документ
«Архитектура решения», HLA и т.п.).
3. Модель влияния компонентов (КЕ) решения на КПЭ (сервисно-ресурсная модель)
должны быть представлены в предлагаемой реализации ТЗ (документ
«Архитектура решения», HLA и т.п.).
4. Наборы метрик мониторинга – модели здоровья – для всех типов КЕ
(конфигурационных единиц) СРМ должны быть представлены в предлагаемой
реализации ТЗ (документ «Архитектура решения», HLA и т.п.).
5. Для каждой метрики мониторинга должны быть определены:

соответствие модели здоровья;

периодичность опроса;

тип данных (логический, целое, срока…);

единица измерения;

условия контроля (нарушение которых изменяет статус метрики и
формирует сообщение в соответствии с указанной критичностью);

уровень критичности (согласно спецификации ITU-T X.733);

инструкция по устранению нештатной ситуации при превышении порогов
метрики;
6. В рамках поставки решения должен быть приобретен необходимый пакет
лицензий системы мониторинга. При этом от производителя решения должно
быть получено официальное заключение о возможности установки и эксплуатации
агентов системы мониторинга, используемой в компании.
7. Для случая, если предусмотрена интеграция с системой мониторинга,
поставляемой вместе с решением, необходимо выполнение следующих
требований:

В случае передачи событий по протоколу SNMP требуется предоставить
описание формата трапов: MIB-файлы, содержащие описания SNMP трапов
NOTIFICATION-TYPE или TRAP-TYPE, в зависимости от версии SNMP.

Для каждого события необходимо определить перечень признаков,
позволяющих определить принадлежность трапа/события к системе (IPадрес источника, ключевое значение в одной из переменных трапа,
возможно, OID или Enterprise трапа).

Требуется предоставить текстовое описание правил дедупликации трапов
(подавление большого кол-ва одинаковых или однотипных событий).
8. Требуется предусмотреть возможность мониторинга таких метрик, как:
3.6.

количество запросов по каждой операции в минуту;

количество ошибок по каждой операции в минуту (общее и по типам
ошибок);

количество сессий, установленных с компонентом;

количество сессий, установленных с компонентом в минуту;

среднее время обработки запроса по типу операции;

количество сообщений в очереди на обработку;

возраст самого старого объекта в очереди;
Требования к времени хранения данных и архивации
1. Требуется хранить в оперативной доступности историю произведенных операций
за последние 3 года.
2. Необходимо предусмотреть возможность выделения и миграции данных старше
36 месяцев, с целью последующей их архивации на внешних носителях, согласно
действующим регламентам Компании.
3.7.
Требования к информационной безопасности
3. Система будет иметь возможность идентификации, аутентификации и
авторизации пользователей в нескольких экземплярах MS Active Directory без
отдельного повторного запроса логина и пароля (SSO).
4. Идентификация и аутентификация внешних систем при предоставлении им данных
будет производиться посредством двухсторонней SSL аутентификации.
5. Система будет позволять предоставлять доступ
предварительно настроенным ролям пользователей.
к
данным,
согласно
6. Система будет протоколировать все действия пользователей, связанные с
изменением данных в системе (аудит).
7. Система будет предоставлять предопределенный набор стандартных ролей с
настроенными для них доступами. Данные роли должны быть заведены в MS
Active Directory
8. Система должна позволять предоставлять доступ к данным, согласно
предварительно настроенным ролям пользователей внутри МГТС с учетом того,
что часть информации является коммерческой тайной.
9. Предоставлять доступ
предполагается.
системе
пользователям
за
пределами
МГТС
не
10. Система обеспечения безопасности системы должна отвечать требованиям ФЗ-152.
3.8.
Требования к пользовательскому интерфейсу системы
1. Требования к рабочим местам пользователей
нормативным документам заказчика:
должны
соответствовать
2. Стандарт "Оснащение автоматизированных рабочих мест" СТ-МГТС-042-2
3. Политики «Обеспечения сотрудников компании ИТ-ресурсами» ПТ-МГТС-022-2.
4. Все интерфейсы пользователей Системы будут выполнены в виде web
приложения.
5. Минимальное разрешение экрана для работы web приложение должно быть
1024x768
6. При обновлении пользователем данных на форме, сама форма не будет
перерисовываться (то есть должна быть реализована с применением технологии
AJAX или её аналогов)
7. Поддерживаемое ПО на клиентских устройствах (браузеры):
1. Internet Explorer v8.0 и выше
2. Mozilla Firefox v11 и выше
3. Google Chrome v18 и выше