абоба

(DegepaJrbHoe rocyAapcrBeHHoe 6ro4xerHoe
o6 pasoBareJr b Hoe yqpelnAeH
(B OPOHEX
CKrrfr r O CvAAp
rr
e Bbr curero o6pa3oBaH rrfl
c TB
EHHbrfr yHr4BE p cnrB T>
(Darcynrrer : Mareuarrrqecrcnfi
HanpauleHlde rloArorosrcu/cuerlkr€rJrbHocrb: 09.02.03 <<IlporpaMMrrpoBaHrre
B
KoMrrbroTepHbrx cIIcTeMax>>
.Ila6oparopHan pa6ora Nb4
rro Ar,rcqlrnJrr{He : [o rcyM eHTrr poBaH rre u ceprnQ
rl rcaq
rrfl
Ha reMy: <<TexHnrrecKoe 3aAaHrre>>
Arrop pa6oru:
3a"uoxH brx [anuu"rr
llropeBnrr
PyronoAnrenb pa6oru:
Knce.rreBa AHna BnnropoBHa
Boponex,2022 r.
1
Приложение №1 к договору №18
от «__» октября 2102 г.
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
на разработку модуля партнерской системы бронирования гостиниц
1. Предмет разработки и общая схема взаимодействия ...................................................... 2
2.
Порядок
передачи
информационных
материалов
между
Заказчиком
и
Исполнителем .............................................................................................................................. 3
3. XML-шлюз и протокол взаимодействия ............................................................................ 3
3.1. Команды для поиска, просмотра и бронирования гостиниц ......................................... 3
3.2. Команды для просмотра и бронирования услуг трансфера........................................... 8
4. Модуль-клиент для установки на веб-сайты .................................................................. 10
5. Интерфейс модуля-клиента ................................................................................................ 11
5.1. Бронирование гостиниц .................................................................................................. 11
5.2. Результаты поиска гостиниц ........................................................................................... 12
5.3. Просмотр одной гостиницы ............................................................................................ 13
5.4. Форма бронирования гостиницы.................................................................................... 17
5.5. Результат бронирования .................................................................................................. 18
5.6. Бронирование трансфера ................................................................................................. 18
6. Личный кабинет для компаний-партнеров..................................................................... 19
6.1. Общие положения ............................................................................................................ 19
6.2. Интерфейс личного кабинета ......................................................................................... 21
7. Требования к разрабатываемым модулям ...................................................................... 25
7.1. Работоспособность в браузерах ...................................................................................... 25
7.2. Требования по интеграции с существующим кодом .................................................... 25
7.3. Требования по производительности .............................................................................. 26
8. Сопровождающая документация....................................................................................... 26
9. Календарный план выполнения работ, сроки предоставления информационных
материалов Заказчиком........................................................................................................... 27
1
2
1. Предмет
взаимодействия
разработки
и
общая
схема
Разрабатываемая система предназначена для обеспечения возможности выполнять
операции поиска, просмотра и бронирования гостиниц, а также бронирования услуг
трансфера посредством внешних модулей, устанавливаемых на сайты компанийпартнеров и работающих с базой данных веб-сайта Заказчика через специальный шлюз.
Общая схема работы показана на рисунке:
Существующая БД
сайта (MySql)
Модуль-клиент
для установки на
веб-сайты
XML-шлюз
Сторонние
модули
Администраторская часть
(личный кабинет) для партнеров
Существующая БД сайта – база данных, к которой подключаются разрабатываемые
модули.
XML-шлюз – набор программных компонент, которые предоставляют внешним
клиентским модуля доступ к определенной информации в базе данных. Программная
архитектура XML-шлюза определяется Исполнителем и в данном техническом задании не
регламентируется.
Компания партнер, желающая создать на своем сайте возможность выполнять
операции поиска и бронирования гостиниц и услуг трансфера, используя базу данных
Заказчика, может либо разместить готовый клиентский модуль, предоставляющий
необходимый функционал, либо реализовать подобный модуль самостоятельно, используя
документацию XML-протокола.
Модуль-клиент для установки на веб-сайты – набор модулей, реализованных на
Javascript. Данный модуль может быть установлен на веб-сайт партнера.
Сторонние модули – модули, которые партнеры могут разработать самостоятельно,
используя документацию по XML-протоколу. Разработка сторонних модулей
Исполнителем данным техническим заданием не предусматривается.
Администраторская часть партнеров предоставляет компаниям-партнерам личный
кабинет на веб-сайте Заказчика. Разработка этого модуля осуществляется с
использованием программных компонент веб-сайта Заказчика.
Более подробно требования и структура вышеприведенных модулей описана в
соответствующих разделах технического задания.
2
3
2. Порядок передачи информационных материалов
между Заказчиком и Исполнителем
В момент подписания данного технического задания Заказчик передает
Исполнителю копию исходных кодов существующего веб-сайта и схему базы данных,
используемой этим сайтом. Указанные файлы записываются на компакт-диск, на котором
ставятся подписи Исполнителя и Заказчика.
В случае, если в процессе разработки по инициативе Заказчика в исходные коды или
схему базы данных вносятся изменения, Заказчик обязан уведомить об этом Исполнителя
не позднее 2-х рабочих дней после внесения изменений. Данные изменения могут повлечь
увеличение стоимости и сроков работ, в этом случае между Исполнителем и Заказчиком
заключается дополнительное соглашение.
Исполнитель на своем сервере разворачивает тестовую копию веб-сайта Заказчика.
Копия защищается от индексирования поисковыми роботами стандартными средствами (с
помощью файла robots.txt). Демонстрация Заказчику функционала разрабатываемых
модулей происходит на тестовой копии. Исходные коды разработанных модулей
передаются Заказчику в порядке, описанном в Договоре, приложением к которому
является настоящее Техническое Задание.
После подписания Акта о приемке услуг, выполненных по данному техническому
заданию, Исполнитель не гарантирует работоспособность разработанных модулей и
соответствие их требованиям, изложенным в данном техническом задании, в случае
изменения Заказчиком исходных кодов веб-сайта или схемы базы данных.
3. XML-шлюз и протокол взаимодействия
Шлюз для обмена данными реализуется на языке PHP. Требуемая версия
интерпретатора – не ниже 5.1.
Конечный адрес шлюза представляет собой ссылку по протоколу HTTP на
определенный PHP-файл на сайте Заказчика. Данный адрес согласуется между Заказчиком
и Исполнителем перед началом работ; изменение адреса впоследствии может потребовать
корректировки программного кода шлюза, что может повлечь увеличение стоимости
работ.
3.1. Команды для поиска, просмотра и бронирования
гостиниц
Взаимодействие с XML-шлюзом со стороны модуля-клиента всегда строится по
следующей схеме:
 Клиент отправляет на шлюз запрос по протоколу HTTP по стандартному (80)
порту. В запросе обязательно содержится:
o Логин партнера;
o Название команды (строка);
o Остальные необходимые параметры, перечисленные в последующих
подпунктах данного раздела;
 Шлюз возвращает клиенту ответ. В каждом ответе обязательно содержится:
o Числовой код результата операции:
3
4


0 – операция выполнена успешно;
1 – операция неуспешна: переданы не все обязательные
параметры или не все параметры переданы в нужном формате;
 2 – операция неуспешна: внутренняя ошибка сервера;
o Параметры, перечисленные в последующих подпунктах данного
раздела, если операция выполнена успешно;
o Текст сообщения об ошибке – содержит информацию о параметрах,
которые указаны ошибочно или не указаны, если операция выполнена
неуспешно из-за некорректно переданных параметров. Конкретный
состав текст сообщения об ошибке выбирается по усмотрению
Исполнителя;
Все ID (стран, городов, гостиниц и т.п.), перечисленные в последующих подпунктах,
совпадают с ID записей из базы данных на сайте Заказчика.
Все передаваемые параметры, перечисленные в последующих подпунктах,
передаются в виде строки. Если параметр является составным (состоит из нескольких
частей), то он описывается в виде подпунктов к этому параметру.
Нижеперечисленные типы параметров проверяются на шлюзе на предмет
корректности формата:
 Все даты передаются в формате ДД.ММ.ГГГГ;
 Все значения времени передаются в формате ЧЧ:ММ;
 Все ID передаются в виде целых чисел;
Все остальные параметры считаются строковым и проверяются лишь на
заполненность, если не указано обратное.
Все передаваемые параметры являются обязательными (их значение должно быть
обязательно передано и не может быть пустым или состоять из одних пробелов), если не
указано обратное.
Конечные имена XML-тегов и атрибутов выбираются исполнителем в процессе
разработки шлюза.
Алгоритм формирования значений в ответе шлюза клиенту (перечень таблиц, из
которых извлекаются данные; бизнес-логика обработки данных) полностью соответствует
алгоритму, используемому для вывода этих значений на страницу на веб-сайта Заказчика,
исходные коды которого передаваются Заказчиком Исполнителю, если явно не указано
иное.
В процессе разработки XML-шлюза возможно незначительное изменение формата
команд на усмотрение Исполнителя. Изменения не уменьшают предоставляемый
функционал.
3.1.1. Команда «Получить список стран»
Команда позволяет получить список стран, в которых доступно бронирование гостиниц.
Передаваемые параметры отсутствуют – только сама команда.
Ответ содержит следующую информацию:
 Список стран, для каждой из которых указывается:
o ID страны;
o Название;
3.1.2. Команда «Получить список городов страны»
4
5
Команда позволяет получить список городов для указанный страны, в которых доступно
бронирование гостиниц.
В запросе передаются следующие параметры:
 ID страны, города которой нужно вернуть;
Ответ содержит следующую информацию:
 Список городов, для каждого из которых указывается:
o ID города;
o Название;
3.1.3. Команда
бронированию»
«Получить
список
гражданств,
доступных
к
Команда позволяет получить список гражданств, которые может выбирать пользователь
при выполнении операции бронирования.
Алгоритм формирования списка аналогичен алгоритму, используемому на сайте
Заказчика в форме бронирования.
Передаваемые параметры отсутствуют – только сама команда.
Ответ содержит следующую информацию:
 Список гражданств, для каждого из которых указывается:
o ID гражданства;
o Название.
3.1.4. Команда «Получить список типов оплаты»
Передаваемые параметры отсутствуют – только сама команда.
Алгоритм формирования списка типов оплаты аналогичен алгоритму, используемому на
сайте Заказчика в форме бронирования.
Ответ содержит следующую информацию:
 Список типов оплаты, для каждой из которых указывается:
o ID тип оплаты;
o Название;
3.1.5. Команда «Получить список гостиниц для города»
Данная команда предназначена для заполнения списка гостиниц в форме поиска для
выбранного города.
В запросе передаются следующие параметры:
 ID города;
Ответ содержит следующую информацию:
 Список гостиниц, для каждой из которых указывается:
o ID гостиницы;
3.1.6. Команда «Получить список гостиниц из формы поиска»
Команда позволяет получить список гостиниц, в которых возможно бронирование (есть
хотя бы 1 свободный номер), по заданным критериям.
В запросе передаются следующие параметры:
 Начальная дата;
5
6





Конечная дата;
Минимальная цена (необязательный параметр);
Максимальная цена (необязательный параметр);
ID города (необязательный параметр);
Количество гостиниц, которые нужно вернуть в запросе (необязательный
параметр, если он не указан – возвращаются все гостиницы);
 Начиная с какой гостиницы из общего списка вернуть список гостиниц
(параметр обязателен при наличии предыдущего параметра);
Шлюз выбирает из базы данных гостиницы, подходящие под переданные критерии
(наличие хотя бы одного номера на указанный период с соответствием по цене, если она
задана и по городу, если он задан) и возвращает результат.
Алгоритм выборки и сортировки соответствует алгоритму, используемому на сайте
Заказчика.
Ответ содержит следующую информацию:
 Список гостиниц; для каждой гостиницы указывается:
o ID гостиницы;
o Название;
o Страна (название и ID);
o Город (название и ID);
o Адрес;
o Метро;
o Список номеров, для каждого из которых указывается:
 ID номера;
 Название;
 Строка с дополнительной информацией (соответствует
значению в ячейке «Доп.информация» на странице со списком
гостиниц после выполнения поиска на сайте Заказчика);
 Список услуг, доступных к бронированию вместе с номером
(соответствует выбору услуг в блоке «Услуги» на странице
бронирования на веб-сайте Заказчика), для каждой из которых
указывается:
 ID услуги;
 Название услуги;
 Общая стоимость размещения за весь указанный срок с
указанием количества поселяемых людей за эту цену.
Возвращаются только доступные варианты поселения по
количеству людей для данного номера (пары значений – «колво человек»/«цена»);
 Стоимость размещения по дням. Для каждого дня указывается:
 Дата этого дня;
 День недели этого дня;
 Стоимость размещения на этот день для каждого из
доступных вариантов поселения по количеству человек
(пары значений – «кол-во человек»/«цена»);
3.1.7. Команда «Получить подробную информацию по гостинице»
6
7
Команда позволяет получить более подробную информацию о конкретной гостинице.
В запросе передаются следующие параметры:
 ID гостиницы;
Ответ содержит следующую информацию:
 Название;
 Тип гостиницы;
 Адрес;
 Город (название и ID);
 Страна (название и ID);
 Количество номеров/этажей;
 Год постройки/реконструкции;
 Расстояние до центра города;
 Ближайшее метро;
 Ближайший аэропорт;
 Ближайший ж/д вокзал;
 Услуги в гостинице: перечисление всех оказываемых услуг, для каждой из
которых указывается:
o Название услуги;
o Путь к иконке, обозначающей данную услугу и расположенной на вебсайте Заказчика;
 Список фотографий гостиницы: простое перечисление в виде ссылок на
изображения;
 Список номеров гостиницы, для каждого из которых указываются те же
параметры, что и в команде «Получить список гостиниц из формы поиска»;
3.1.8. Команда «Получить описание, цену и наличие номера»
Команда позволяет получить информацию о наличии цен и мест по конкретному номеру.
Передаваемые параметры:
 ID номера;
 Дата заезда;
 Дата выезда;
Ответ содержит следующую информацию:
 Те же параметры, представленные в той же форме, что и в ветке «Список
номеров, для каждого из которых указывается» в команде «Получить список
гостиниц»;
3.1.9. Команда «Выполнить бронирование»
Автоматическая регистрация пользователя при выполнении бронирования не реализуется.
Данные сначала попадают в отдельную таблицу с временными заказами (эта таблица в
момент подписания Технического Задания не существует и будет создана Исполнителем,
структура выбирается на его усмотрение) и только после подтверждения партнером – в
основную таблицу с заказами, существующую на момент подписания Технического
Задания на веб-сайте Заказчика.
Передаваемые параметры:
7
8






Фамилия человека, выполняющего бронирование;
Имя человека, выполняющего бронирование;
Электронный адрес человека, выполняющего бронирование;
Контактный телефон человека, выполняющего бронирование;
ID бронируемой гостиницы;
Список бронируемых номеров, для каждого из которых указывается:
o ID номера;
o Количество заселяемых людей в данный номер (не может превышать
количество людей, доступных к заселению в данный номер);
o Дата заезда;
o Время заезда – любое время;
o Дата выезда;
o Время выезда – любое время;
o Услуги – для каждой из заказываемых услуг передается ее ID;
o Список проживающих, для каждого из которых указывается:
 Фамилия;
 Имя;
 Пол (муж/жен);
 Дата рождения (необязательный параметр);
 ID гражданства
 ID типа оплаты;
 Комментарии (необязательный параметр);
Ответ содержит следующую информацию:
 Результат операции: успех/неуспех (без конкретизации);
3.2. Команды
трансфера
для
просмотра
и
бронирования
услуг
ID значений (например, ID города) в данном наборе команд могут не совпадать с ID
аналогичных значений в наборе команд по бронированию гостиниц.
3.2.1. Команда «Получить список городов, в которых доступно
бронирование услуг трансфера»
Передаваемые параметры, кроме самой команды, отсутствуют.
Ответ содержит следующую информацию:
 ID города;
 Название;
3.2.2. Команда «Получить список классов транспорта»
Передаваемые параметры, кроме самой команды, отсутствуют.
Ответ содержит следующую информацию:
 ID класса транспорта;
 Название класса;
3.2.3. Команда «Выполнить бронирование услуг трансфера»
8
9
Команда позволяет выполнить процедуру бронирования. Автоматическая регистрация
пользователя при этом не реализуется. Данные сначала попадают в отдельную таблицу с
временными заказами (эта таблица в момент подписания Технического Задания не
существует и будет создана Исполнителем, структура выбирается на его усмотрение) и
только после подтверждения партнером – в основную таблицу с заказами, существующую
на момент подписания Технического Задания на веб-сайте Заказчика.
Передаваемые параметры:
 ID города;
 Дата трансфера;
 Фамилия пассажира;
 Имя пассажира;
 Телефон пассажира;
 Количество пассажиров (число от 1 до 4 включительно);
 Класс транспорта, один из фиксированных вариантов (передается в виде
текстовой строки):
o «Комфорт класс»
o «Бизнес класс»
o «Премиум класс»;
 Время подачи;
 Тип подачи, один из фиксированных вариантов (передается в виде текстовой
строки):
o «Адрес»;
o «Аэропорт»;
o «Ж/д вокзал»;
 В случае варианта подачи «Адрес» также передаются следующие
параметры:
o Адрес;
 В случае варианта подачи «Аэропорт» также передаются следующие
параметры:
o Аэропорт;
o № рейса;
o Прибытие из;
 В случае варианта подачи «Адрес» также передаются следующие
параметры:
o Вокзал;
o № поезда;
o № вагона;
o Прибытие из;
 Пункт назначения;
 Комментарии к маршруту (необязательный параметр);
 Фамилия человека, выполняющего бронирование;
 Имя человека, выполняющего бронирование;
 Телефон человека, выполняющего бронирование;
 Адрес электронной почты человека, выполняющего бронирование;
Ответ содержит следующую информацию:
9
10

Результат операции (два варианта: «Ок» и «Ошибка», без конкретизации);
3.2.4. Команда «Получить список цен»
Передаваемые параметры:
 ID города;
Ответ содержит следующую информацию:
 Готовую HTML-разметку с таблицей цен для указанного города. Разметка
совпадает с существующей разметкой цен на трансфер на веб-сайте
заказчика. Угловые скобки HTML-тегов кодируются псевдокодами (< и
>).
4. Модуль-клиент для установки на веб-сайты
Модуль реализуется в виде одного или нескольких Javascript-файлов. Для
подключения модуля на веб-сайт необходимо в желаемом месте размещения в HTMLкоде страницы вставить тег-ссылку на один javascript-файл. Если модуль реализуется в
нескольких файлах, то тег-ссылка по-прежнему обращается к одному файлу, который
является «точкой входа», т.е. сам подгружает остальные необходимые javascript-файлы.
Предусматривается две «точки входа»:
 На подмодуль бронирования гостиниц;
 На подмодуль бронирования (заказа) услуг трансфера.
Модуль самостоятельно формирует и размещает на странице все элементы
интерфейса. Весь функционал реализуется с помощью Javascript и работает в пределах
одной веб-страницы, выполняя все операции без перезагрузки страницы. Каждый из двух
вышеперечисленных модулей должен быть расположен на отдельной странице.
Дополнительно на каждую точку входа может быть указан тег-ссылка на файл со
стилями (CSS), в котором компания-партнер может изменить отображаемый стиль
самостоятельно. В случае, если ссылка на CSS-файл не указывается, используется CSSфайл по умолчанию.
Javascript-файлы располагаются на веб-сервере Заказчика.
В виду особенностей применения клиентских скриптов, позволяющих любому
желающему загрузить на свой ПК все Javascript-файлы с веб-сайта и просмотреть их
содержимое (структуру команд и ID партнера), возможна отсылка заказов (в т.ч.
злоумышленником) на XML-шлюз не с реального сайта партнера.
CSS-файлы, используемые по умолчанию, также располагаются на веб-сервере
Заказчика. Если компания-партнер изменяет CSS-файл/файлы, то она располагает эти
файлы на своем веб-сайте и корректирует тег-ссылку на данные файлы.
Каждый стиль в CSS-файле, используемом по умолчанию, снабжается текстовым
комментарием на русском языке, описывающем, внешний вид какого визуального
элемента/элементов задается данным стилем. Детализация и документация по каждому
параметру стиля не предоставляется.
В следующем разделе приводится схематичное описание интерфейса модуляклиента. Для всего интерфейса также справедливо следующее:
 Переключение между отображаемой информацией (смена форм, переход к
списку гостиниц и т.п.) выполняется без какой-либо анимации;
10
11

По отображаемым фотографиям гостиниц и их номеров по умолчанию нельзя
кликнуть и получить увеличенную версию, если явно не указано иное;
 До начала работ по разработке модуля-клиента Заказчик может заменить
стандартные кнопки на графические, предоставив Исполнителю
окончательный вариант кнопки в виде gif или png изображения;
 Везде, где предполагается ввод даты с помощью формы-календаря,
используется следующая форма: http://jqueryui.com/demos/datepicker/ (по
состоянию на дату подписания данного технического задания);
 Поля ввода, в названии которых в конце имеется символ «звездочка»,
являются обязательными. Проверка заполнения поля выполняется
непосредственно в клиентском модуле. В случае незаполнения хотя бы
одного из необходимых полей данные на шлюз не отправляются.
Предусматривается только проверка полей на заполненность: заполненным
считается поле, состоящее более, чем из двух символов. Пробелы в начале и в
конце символами не считаются;
 Все динамические параметры (например, название гостиницы), выводимые в
интерфейсе, формируются по тому же принципу, что и аналогичные
параметры на оригинальном сайте Заказчика (на момент подписания данного
технического задания), поскольку эти параметры запрашиваются через XMLшлюз, логика работы которого, как было указано ранее, соответствует логике
формирования значений на указанном сайте Заказчика.
Дизайн всех разделов модуля-клиента предоставляется Заказчиком. Дизайн передается в
виде графических файлов формата PSD (Adobe Photoshop). Верстка дизайна в HTMLстраницы выполняется Исполнителем.
5. Интерфейс модуля-клиента
5.1. Бронирование гостиниц
11
12
5.2. Результаты поиска гостиниц
5.2.1. Комментарии
N Описание
1
Отображаются все номера страниц (без пропусков). Количество записей на страницу задается в программном коде
клиентского модуля.
12
13
N Описание
2
При показе результатов поиска в форме поиска автоматически остаются заполненными все значения, введеные
пользователем.
3
Если в результате не найдено ни одной гостиницы под заданные критерии, то под данной строкой выводится надпись
"По вашему запросу не найдено ни одной гостиницы!".
5.3. Просмотр одной гостиницы
13
14
5.3.1. Панель информации о гостинице
5.3.1.1. Информация
5.3.1.2. Комментарии
N Описание
1
Данные иконки соответствуют услугам, предоставляющимся гостиницей. Иконки предоставляются заказчиком.
Показываются
иконки
только
тех
услуг,
которые
есть
в
гостинице.
При наведении на иконку появляется подсказка (реализованная с помощью атрибута title тега img) с названием услуги.
14
15
5.3.1.3. Галерея
15
16
5.3.2. Панель с увеличенным изображением
5.3.2.1. Основное
5.3.2.2. Комментарии
N Описание
1
Показывает предыдущую фотографию. При достижении начала списка фотографий показывается последняя
фотография (т.е. кольцевая структура).
2
Показывает следующую фотографию. При достижении конца списка фотографий показывается первая фотография (т.е.
кольцевая структура).
16
17
5.4. Форма бронирования гостиницы
5.4.1. Комментарии
N Описание
1
Вне зависимости от номера предлагается заполнить данные по трем проживающим. Если проживающих меньше, то их
блоки
не
заполняются.
Обязательно заполнение данных хотя бы по одному проживающему.
17
18
N Описание
2
Отображаются все номера в нужном количестве, выбранные к бронированию на предыдущем шаге.
5.4.2. Сообщение об ошибке
5.4.2.1. Заполнены не все поля
5.5. Результат бронирования
5.6. Бронирование трансфера
18
19
5.6.1. Комментарии
N Описание
1
Дата, выбирается формой-календарем.
3
В клиентском модуле поля, следующие за блоком полей "адрес", автоматически поднимаются наверх в зависимости от
кол-ва полей над ними, ликвидируя таким образом пустое пространство.
5
Информация по ценам запрашивается с сервера и автоматически обновляется при смене выбранного города.
5.6.2. Панель с полями по разным способам подачи
5.6.2.1. Адрес
5.6.2.2. Аэропорт
5.6.2.3. Ж/д вокзал
5.6.3. Сообщение об ошибке
5.6.3.1. Заполнены не все поля
6. Личный кабинет для компаний-партнеров
6.1. Общие положения
Для редактирования настроек и просмотра информации по накопленным заказам
компании-партнеры используют личный кабинет, расположенный на веб-сайте Заказчика.
Поскольку на существующем сайте уже предусмотрен механизм регистрации и личный
кабинет, то разработка данного подмодуля системы ведется по следующим принципам:
19
20

Все юридические лица, зарегистрированные или потенциальные, могут
использовать партнерскую систему, т.е. являются партнерами;
 Механизм регистрации юридических лиц остается прежним (в таком виде,
как он реализован на момент подписания Технического Задания на веб-сайте
Заказчика);
 Юридическое лицо, собирающееся принять участие в партнерской системе,
должно указать в личном кабинете адрес своего веб-сайта. Механизм
редактирования адреса веб-сайта реализуется Исполнителем по следующим
принципам:
o В таблице базы данных, в которой хранится информация о
юридических лицах, Исполнитель добавляет новую колонку для
хранения адреса веб-сайта компании-партнера;
o Исполнитель модернизирует существующую страницу редактирования
личных данных в личном кабинете, удаляя старый блок партнерской
системы и добавляя поля, определенные в разделе, описывающем
интерфейс личного кабинета;
 Все заказы на бронирование гостиниц, оформленные через XML-шлюз (т.е.
через партнерскую систему), попадают сначала в таблицу с временными
заявки (таблица создается Исполнителем). Данные из этой таблицы
компания-партнер видит в личном кабинете в разделе «Бронирования
гостиниц». По каждой заявке можно посмотреть дополнительную
информацию. После подтверждения заявки нажатием на соответствующую
ссылку/кнопку, заявка переносится в общую таблицу заказов сайта (таблицу,
в которую попадают все заказы, оформляемые через веб-сайт Заказчика, на
момент подписания Технического Задания). Дальнейшая работа с заказом
остается без изменений относительно текущей работающей версии у
Заказчика (Исполнитель не вносит туда изменений).
 Заказы на трансфер работают по аналогичному принципу. Для них создается
отдельная таблица на временные заявки и отдельная страничка в личном
кабинете для просмотра пришедших заявок.
 Просмотр финансовой статистики осуществляется за выбранный партнером
период. В формировании суммы комиссионных участвуют только
подтвержденные заказы – заказы, которые находятся в таблице Orders. Сумма
комиссионных рассчитывается как процент от суммы заказа. Процент
возвращается из PHP-функции, которую реализует Заказчик. Функция
принимает следующие параметры:
o ID партнера;
o Тип заказа – гостиница или трансфер (строка/булево значение);
o ID гостиницы.
Интерфейс личного кабинета юридических лиц приведен в соответствующем разделе. Там
же обозначены существующие разделы и блоки, которые не меняются Исполнителем.
Кроме того, интерфейс личного кабинета компаний-партнеров имеет следующие
особенности:
 Все действия (подтверждение, просмотр подробной информации и т.п.)
выполняются с перезагрузкой страницы, если явно не указано обратное;
20
21


Внешний вид (дизайн) новых разделов личного кабинета полностью
повторяет внешний вид существующих разделов личного кабинета;
По желанию Заказчика стандартные кнопки и текстовые гиперссылки могут
быть заменены на графические, предоставленные Заказчиком;
6.2. Интерфейс личного кабинета
6.2.1. Личный кабинет партнера - ваши данные
21
22
6.2.2. Личный кабинет партнера - ваши данные - редактирование
6.2.3. Личный кабинет партнера - бронирования гостиниц
22
23
6.2.4. Личный кабинет партнера - бронирования гостиниц подробности
6.2.5. Личный
подтверждение
кабинет
партнера
-
бронированя
6.2.6. Личный кабинет партнера - заказы трансфера
23
гостиниц
-
24
6.2.7. Личный кабинет партнера - заказы трансфера - подробности
6.2.7.1. Комментарии
N Описание
1
В зависимости от выбранного типа подачи отображаются специфические поля именно этого типа подачи (вокзал, вагон,
город для ЖД и адрес для подачи по адресу).
6.2.8. Личный
подтверждение
кабинет
партнера
-
заказы
6.2.9. Личный кабинет партнера - статистика
24
трансфера
-
25
6.2.9.1. Комментарии
N Описание
1
По умолчанию - за последний месяц (текущая дата минус 30 дней).
2
Для установки даты используется форма-календарик.
3
Для установки даты используется форма-календарик.
7. Требования к разрабатываемым модулям
7.1. Работоспособность в браузерах
Работоспособность всех модулей, имеющих интерфейс, отображаемый в веб-браузере,
гарантируется в следующих веб-браузерах (для каждого указана минимальная версия, в
которой гарантируется работоспособность):
 Internet Explorer 7;
 Opera 10;
 Firefox 3.6;
 Google Chrome 4.0;
Работоспособность не гарантируется в более старых версиях, предварительных (бета и
т.п.) версиях, вышедших после подписания данного технического задания версиях, а
также в случае наличия у пользователя установленных надстроек («баров»), а также в
случае применения кэширующих прокси-серверов и межсетевых экранов, частично или
полностью блокирующих трафик по протоколу HTTP (порт 80).
7.2. Требования по интеграции с существующим кодом
При разработке модулей согласно данному техническому заданию Исполнитель, как
правило, создает новые файлы с исходным кодом, которые могут использовать
функционал существующих (разработанных ранее Заказчиком) файлов с исходным кодом.
В случае необходимости Исполнителем могут вноситься изменения в существующие
файлы и/или схему базы данных с обязательным предварительным резервным
копированием изменяемых файлов. При этом комментариями обозначаются начало и
конец измененных блоков.
Исполнитель может вносить комментарии в существующие файлы на свое
усмотрение.
Количество строк с комментариями – не менее 10% от количества добавляемых или
изменяемых строк с программным кодом как в новых, так и в измененных файлах.
Следование определенному стилю оформления программного кода не требуется.
При реализации функционала, частично или полностью совпадающего с уже
существующим на сайте, Исполнитель вправе самостоятельно решать, использовать ли
при этом существующие исходные коды или реализовать данный функционал
самостоятельно.
25
26
7.3. Требования по производительности
7.3.1. Производительность XML-шлюза
Учитывая следующие факты:
 Возможность изменения аппаратной конфигурации сервера Заказчиком;
 Возможность изменения нагрузки на сервер (например, изменение
посещаемости);
 Повышенные требования вычислительных ресурсов при работе с XMLдокументами в силу природы XML-данных (большое количество текстовой
информации),
требования по производительности XML-шлюза устанавливаются следующим образом:
 Среднее (за 10 последних запросов) время приема запроса и формирования
ответа по любой из команд XML-шлюза не может превышать среднее (за 10
запросов) время формирования страницы с результатами поиска гостиницы
(http://www.domain.ru/ru/search/, без указания конкретной гостиницы в форме
поиска), умноженное на коэффициент 1,3. В случае необходимости измерение
и сравнение описанных показателей должно проводиться одновременно (с
расхождением не более 30 секунд) для XML-шлюза и эталонной страницы.
7.3.2. Производительность администраторской части интерфейса
для партнеров
Учитывая тот факт, что доработка функционала существующей администраторской части
приведет к усложнению алгоритмов работы, устанавливается следующее требование по
производительности:
 Время формирования страницы доработанной администраторской части не
должно превышать время формирования исходной страницы, умноженное на
коэффициент 1,2. В случае необходимости измерение проводится
одновременно (с расхождением не более 30 секунд) на обоих версиях
страницы.
7.3.3. Производительность модуля-клиента
Производительность модуля-клиента данным техническим заданием не регламентируется,
т.к. скорость работы Javascript-модулей будет зависеть от производительности и
загруженности ПК конечного пользователя сайта, производительности используемого им
веб-браузера, скорости интернет-соединения пользователя и загруженности веб-сервера
Заказчика.
8. Сопровождающая документация
Вместе с разработанными модулями Исполнитель передает Заказчику документацию по
XML-протоколу в следующем виде:
 Документация по каждой команде XML-шлюза:
o Название на русском языке;
o Описание выполняемых командой действий;
26
27
o XSD-схема команды и ответов (результатов выполнения);
o Пример в виде XML-запроса и XML-ответа;
 Инструкция по установке клиентского Javascript-модуля на сайт;
Документация передается в виде документа Word. Верстка документации в HTML не
осуществляется.
9. Календарный план выполнения работ, сроки
предоставления
информационных
материалов
Заказчиком
В приведенной таблице указан срок реализации каждого этапа работ; датой начала
первого этапа является дата начала работ в соответствии с Договором, приложением к
которому является настоящее Техническое Задание и/или дата предоставления
необходимых информационных материалов (что наступит позже). Датой начала
последующих этапов является дата завершения предыдущего этапа и/или дата
предоставления необходимых информационных материалов (что наступит позже).
Наименование этапа
работ
Разработка XML-шлюза
(без
команд
приема
заказов)
Разработка
модуляклиента
Доработка
личного
кабинета
компанийпартнеров
Тестирование
Срок
выполнения,
рабочих дней
10
31
10
Информационные материалы,
которые должны быть
представлены Заказчиком
Схема базы данных, исходные
коды сайта
Дизайн модуля-клиента
PHP-функция,
возвращающая
процент комиссионных партнера
4
Устранение неточностей,
оптимизация
производительности
8
Итого
63
27