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

Экспертное заключение
о соответствии предлагаемых потенциальными поставщиками закупаемых услуг требованиям технической
спецификации по проектированию, разработке и внедрению прототипа «Портал открытых данных»
Дата: «03» декабря 2013 г.
Рассмотрев представленную потенциальными поставщиками технические спецификации на соответствие техническим требованиям по
закупу услуг по проектированию, разработке и внедрению прототипа «Портал открытых данных», сделано следующее заключение:
№
1
1.1
Требование
ТОО «Zero Gravity»
Требования к потенциальному поставщику
Не менее 1 (одного) квалифицированного специалиста в
области управления проектами (в подтверждение к
технической спецификации приложить электронную копию
Соответствует
нотариально засвидетельствованной копии международного
сертификата, выданного PMI, либо IPMA)
Не менее 1 (одного) квалифицированного специалиста в
области управления рисками (в подтверждение к технической
спецификации приложить электронную копию нотариально
Соответствует
Обязательные
заверенной копии международного сертификата FRM,
требования к составу
выданного GARP, либо международного сертификата PRM,
проектной группы
выданного PRMIA)
Не менее 1 (одного) кандидата технических наук (в
подтверждение к технической спецификации приложить
Соответствует
электронную копию нотариально засвидетельствованных
копий соответствующих документов)
Не менее 1 (одного) кандидата экономических наук (в
подтверждение к технической спецификации приложить
Соответствует
электронную копию нотариально засвидетельствованных
копий соответствующих документов)
ТОО «Prime Source»
Соответствует
Соответствует
Соответствует
Соответствует
1.2
1.3
1.4
2
2.1
3
3.1
Потенциальный поставщик должен предоставить электронную копию официального
письма, заверенного печатью Потенциального поставщика, содержащее сведения о
Соответствует
составе проектной группы с указанием задействованных сотрудников Потенциального
поставщика.
Потенциальный поставщик должен предоставить подтверждение успешно завершенных
проектов в области информационных технологий путем предоставления как минимум
Соответствует
15-ти рекомендательных писем
Потенциальный поставщик должен иметь офис на территории Республики Казахстан
(подтверждается
оригиналами,
либо
нотариально
заверенными
копиями
Соответствует
соответствующих документов)
Требования к структуре Портала
Портал должен содержать следующие функциональные подсистемы:
 Подсистема информационного взаимодействия с источниками открытых данных и
хранения открытых данных - предназначена для централизованного учета
информации о наличии, форматах, способах хранения и использования имеющихся
на сайтах органов государственной власти и органов местного самоуправления
наборов открытых данных, в том числе ведения единого реестра открытых
государственных данных, единого хранилища открытых данных;
Соответствует
 Подсистема коллективной работы и обсуждения - предназначена для обмена
мнениями между заинтересованными пользователями различных тематик области
открытых данных, для возможности всеобщего обсуждения и контроля качества
открытых данных;
 Подсистема администрирования - предназначена для управления доступом,
резервного копирования и восстановления, диагностирования портала и управления
его конфигурациями.
Требования к режимам функционирования Портала
Портал должен обеспечивать функционирование в следующих режимах:
 штатный режим (режим, обеспечивающий выполнение функций Портала в полном
объеме силами Заказчика и Исполнителя);
Соответствует
 сервисный режим (режим для проведения переконфигурирования, внесения
обновлений и профилактического обслуживания);
 аварийный режим.
Основным режимом функционирования Портала должен являться штатный режим,
Соответствует
Соответствует
Соответствует
Соответствует
Соответствует
при котором:
 клиентское программное обеспечение на рабочих местах пользователей
обеспечивают
возможность
круглосуточного
функционирования,
с
регламентированными перерывами на техническое обслуживание и обновление
программного обеспечения;
 серверное программное обеспечение обеспечивает возможность круглосуточного
функционирования с регламентированными перерывами на техническое
обслуживание и обновление программного обеспечения.
В штатном режиме функционирования Портал должен обеспечивать:
 работу пользователей в режиме – 24 часа в день, 7 дней в неделю;
 коэффициент доступности не ниже 99,97%;
 выполнение всех функций в полном объеме.
Для обеспечения штатного режима функционирования Портала необходимо
соблюдать требования и выдерживать условия эксплуатации программного
обеспечения, указанные в технической документации в составе:
 руководства пользователя на подсистемы Портала;
 руководство администратора Портала.
Сервисный режим функционирования должен использоваться для выполнения
операций подготовки и проведения испытаний или настройки Портала. В данном
режиме Портал или его подсистемы становятся недоступными для групп пользователей.
В данном режиме осуществляется:
 проведение на сервере Портала регламентных и других работ, предусмотренных
инструкцией по эксплуатации на сервере Портала;
 модернизация аппаратно-программного комплекса Портала;
 модернизация Портала или отдельных подсистем.
В сервисном режиме Портал должен обеспечивать работоспособность подсистемы
хранения данных и должен предоставляться инструментарий администрирования.
Аварийный режим функционирования Портала характеризуется отказом в работе
Портала. Переход Портала в аварийный режим происходит по причине нарушения
работоспособности Портала или одной из подсистем. В аварийном режиме
функционирования Портала должна обеспечиваться работоспособность подсистемы
хранения данных и должен предоставляться инструментарий администрирования.
4
4.1
5
5.1
Требования к проведению диагностических работ на Портале
Портал должен иметь возможность предоставлять инструменты диагностирования
основных процессов Портала, мониторинга процессов, выполняемых Порталом.
При возникновении аварийных ситуаций, либо ошибок в программном обеспечении,
инструменты диагностики должны позволять сохранять набор информации,
необходимой для идентификации и устранения проблемы.
Перечень аварийных ситуаций, приводящих к отказу системы и (или) ее
компонентов:
 Отказы в Системе электроснабжения:
 отказы технических средств подсистемы электропитания Системы;
 полное отключение электроэнергии.
 Отказы комплекса технических средств (аппаратных средств):
Соответствует
 отказы серверного оборудования;
 отказы АРМ пользователей;
 отказы сетевого, телекоммуникационного оборудования и каналов связи;
 отказы оборудования резервного копирования информации.
 Отказы программных средств
 Отказы в результате ошибок обслуживающего персонала и пользователей
Кроме того, программные модули должны обеспечивать ведение журналов, в
которых должны автоматически фиксироваться возникающие нештатные ситуации и
ошибки (силами заказчика и исполнителя). При возникновении аварийных ситуаций,
данные журналы должны позволять сохранять полный набор информации, необходимой
разработчику для идентификации проблемы.
Перспективы развития и модернизации Портала
Разрабатываемый Портал должен предусматривать возможность его дальнейшего
развития, модификации и включения новых функциональных задач, в том числе в
следующих направлениях:
 увеличение количества классификационных групп наборов данных и
количественного объема открытых данных, принимаемых Порталом от ИнтернетСоответствует
ресурсов
первоисточников
центральных
государственных
и
местных
исполнительных органов;
 автоматизация контроля форматов представления данных публикуемых
центральными государственными и местными исполнительными органами;
Соответствует
Соответствует
6
6.1
 расширение функциональности Портала по обеспечению обратной связи с
пользователями, в том числе в части комментирования и дополнения данных,
ведения обсуждения данных и выставления их рейтинга, отслеживания состояния
обращений пользователей и результатов их обработки;
 расширение количества справочников и классификаторов, получаемых из
официальных сайтов представителей государственных органов;
 обеспечение взаимодействия с официальными Интернет-ресурсами центральных
государственных и местных исполнительных органов;
 публикация данных, справочников и классификаторов на Портале в разрабатываемых
и планируемых стандартах публикации Открытых данных;
 интеграция с порталами открытых данных иных государственных органов;
 создание консолидированной аналитической отчетности для государственных
органов и граждан, по результатам работы портала открытых данных;
 увеличение количества пользователей Портала и внешних прикладных программ,
использующих данные, накопленные Системой, без ущерба для надежности и
скорости работы Портала за счет увеличения производительности технических
средств;
 замена версий программного обеспечения;
 модернизация технических средств.
В рамках развития Портала возможны изменения архитектуры и перепроектирования
Портала, согласованные в дополнительной технической спецификации и техническом
задании.
Требования к резервному копированию Портала
Портал должен обеспечивать возможность автоматического резервного копирования
по расписанию всех компонентов и данных, необходимых для полноценного
восстановления системы до состояния, в котором она находилась непосредственно
перед сбоем. Для целей резервного копирования допускается использование функций
общесистемного программного обеспечения (операционной системы, СУБД) при
Соответствует
условии обеспечения полноты копирования и восстановления.
Порядок проведения резервного копирования и восстановления системы должен
быть полно описан в разрабатываемой Исполнителем эксплуатационной документации.
В период действия договора Исполнитель должен обеспечить возможность
осуществления еженедельного резервного копирования данных и компонентов Портала
Соответствует
(совместно с Заказчиком).
7
7.1
8
8.1
9
9.1
10
10.1
11
11.1
Требования к журналированию событий
Портал должен обеспечивать автоматическое ведение журнала событий, в котором
фиксируются все действия пользователей Портала, приводящие к удалению, изменению
или добавлению информации на Портале.
Необходимо обеспечить недоступность изменения записей журнала для всех
Соответствует
пользователей Портала. Необходимо обеспечить доступность функции очистки логов
только для специальной роли пользователя. Функция очистки журнала должна
автоматически сопровождаться обязательной записью данного события после очистки в
журнал событий.
Требования к обеспечению защиты данных
Для обеспечения защиты данных, хранящихся и обрабатываемых системой
необходимо:
 определить и соответствующим образом описать объекты данных, с которыми
Соответствует
работает система, классифицировать данные в соответствии с законодательством
Республики Казахстан;
 описать требуемые меры обеспечения безопасности в руководстве Пользователя.
Требования по сохранности информации при авариях
На Портале должна быть предусмотрена возможность обеспечения сохранности
данных силами Заказчика в следующих ситуациях:
 сбой или аварийное отключение питания;
 выход из строя технических средств, на которых осуществляется эксплуатация
Соответствует
Портала;
 сбой из-за ошибочных действий персонала, в том числе умышленное уничтожение
или искажение прикладного, специального и общего программного обеспечения.
Сохранность информации в БД должна обеспечиваться штатными средствами СУБД
резервного копирования и восстановления после сбоев.
Требования к защите от влияния внешних воздействий
Защита от влияния внешних воздействий должна обеспечиваться средствами
Соответствует
аппаратно-программного комплекса Заказчика.
Требования к программному обеспечению Портала
Качество программных средств должно обеспечивать выполнение требований,
Соответствует
предъявляемых к Порталу в целом и к функциям Портала.
Соответствует
Соответствует
Соответствует
Соответствует
Соответствует
12
12.1
При создании Портала должно использоваться свободное программное обеспечение
(непроприетарное программное обеспечение).
Портал должен быть разработан с использованием PHP-фреймворков 3-го поколения,
СУБД MySQL.
Общее программное обеспечение (ОПО) должно состоять из следующих
компонентов:
 операционная(ые) система(ы);
 СУБД;
 прикладные программы;
 телекоммуникационные программы;
 программы защиты от НСД;
 антивирусные средства;
 программные средства мониторинга Портала.
На серверах Портала должны использоваться многозадачные операционные системы.
Специальное программное обеспечение (СПО) должно базироваться на принципах
модульности и концепции «открытых систем», предусматривающих возможность
независимой разработки и включения в Портал функциональных модулей, а также
обеспечивающих возможность информационного взаимодействия с другими системами.
При этом концепция «открытых систем» предполагает независимость разрабатываемых
программных средств от используемых аппаратных и системных платформ, что
поддерживается
современными
системными
программными
средствами
(операционными системами и СУБД), использующими стандарты открытых систем.
Портал должен корректно поддерживать многопользовательскую работу.
Использование инструментальных средств для разработки программного
обеспечения Портала не должно нарушать права других лиц.
Требования к визуальному отображению Портала
Дизайн Портала должен соответствовать современным требованиям к удобству
использования и применения Интернет-ресурсов.
Интерфейс Портала должен быть разработан максимально понятным, удобным и не
перегруженным графическими элементами. Навигационные элементы должны быть
Соответствует
выполнены в удобной для пользователя форме. Средства редактирования информации
должны полностью удовлетворять общепринятым требованиям в части использования
функциональных клавиш, режимов работы, поиска, использования оконной системы.
Соответствует
13
13.1
14
14.1
15
15.1
Ввод-вывод данных системы, прием управляющих команд и отображение результатов
их исполнения должны быть выполнены в интерактивном режиме. Интерфейс должен
соответствовать современным эргономическим требованиям и обеспечивать удобный
доступ к основным функциям и операциям Портала.
Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме
системных сообщений) должны быть реализованы на трех языках: казахском, русском и
английском.
Работа с административной системой
Административная система должна представлять собой модуль, слабо связанный с
остальными частями приложения. Он будет собирать данные о зарегистрированных
сервисах группы «admin», через систему управления сервисами, реализованную в
переопределенном классе приложения. Далее, модуль предоставляет человекопонятную
навигацию по сервисам и макет-оболочку с общим стилевым оформлением. Никаких
управляющих действий административная система производить не должна – она лишь
передает управление и аргументы соответствующим действиям административных
сервисов.
Работа с RBAC
Все действия, выполняемые системой, прежде должны проходить через фильтр
RBAC (Roled Based Access Control). RBAC-система выясняет набор прав пользователя,
и в соответствии с ними определяет, может ли пользователь сделать то, что он
намеревается. Кроме того, система управления пользователями предоставляет
внутреннее API для работы с RBAC, позволяющее самостоятельно выполнить проверки
на доступ к тем или иным элементам интерфейса или принять решение на основании
текущего состояния.
Модуль Users
Реализующий пользовательскую систему, должен предоставлять удобный
административный интерфейс управления пользователями и ролями. Используя этот
инструменты, необходимо создать роли, необходимые для функционирования проекта в
рамках поставленной задачи:
root - неограниченный доступ, имеют только разработчики;
Администратор – разрешено большинство управляющих действий;
Модератор – разрешено доступ к модераторскому кабинету;
Государственный орган – создание новых файлов;
Соответствует
Соответствует
Соответствует
Соответствует
Соответствует
Соответствует
16
16.1
17
17.1
18
18.1
Разработчик – создание новых версий существующих файлов;
Гость – любой неаутентифицированный пользователь.
Конъюнктура приложения
В частности, реализация работы с файлами и редакциями, а также, модераторский
кабинет должна быть тесно связана с этими ролями, поэтому ни в коем случае нельзя
выключать их, либо удалять.
Также, в конъюнктуре приложения должна быть реализована надстройка над RBACсистемой для работы с профайлом пользователя и модераторской системой (в
соответствии с техническим заданием проекта).
Работа с файлами и редакциями
Система работы файлами и редакциями должна выступать значительной частью
конъюнктуры приложения.
Базовым понятием этой системы является понятие «файл», которое, по сути является
лишь подмножеством материалов Struct – относящимся к категории, обозначенной как
категория файлов. Таким образом, для работы с файлами, применяются стандартные
средства модуля Struct. Также, основная информация о файлах должна быть доступна из
административного сервиса, предоставляемого модулем Struct.
Однако работа с непосредственной информацией о физических файлах (в
определенных форматах) должна производиться с помощью связанной модели,
описывающей редакции файлов. Таким образом будет устроена система
версионирования данных в файлах. Каждый файл может содержать множество
редакций, которые должны быть одобрены модераторами, и последняя из них является
текущим состоянием файла.
Для упрощения работы с файлами и редакциями необходимо реализовать
соответствующее внутреннее API. В нем должна быть реализована работа с логами, в
которые записывается каждое произведенное над файлами и их редакциями действие.
Еще одной важной составляющей системы работы с файлами и редакциями является
сложная система учета и подсчета рейтинга файлов.
Рейтинг файлов
У каждого набора данных должно быть пользовательское голосование в виде
звездочек, от 1 до 5 с возможностью изменить свой голос в дальнейшем.
Рейтинг набора данных считается исходя из следующей формулы расчета рейтинга:
Rating = (q/(q+max))*s + (max/(q+max))*n + (k/(k+t))*w
Соответствует
Соответствует
Соответствует
Соответствует
Соответствует
Соответствует
19
19.1
20
20.1
значения переменных:
q – количество голосов за набор данных;
max – порог голосов;
s – среднее арифметическое всех голосов за набор данных;
n – среднее значение рейтинга всех данных;
k – количество подключений к набору данных;
t – сумма всех подключений;
w – среднее значение всех подключений ко данным
Следовательно у каждого набора данных необходимо сохранять в моделях базы
данных следующие дополнительные статистические данные: голоса пользовательского
рейтинга (с временем первого голоса и временем изменения), подключения по API к
наборам данных (с временем и IP адресом клиента), переменную max (порог голосов)
предоставить для редактирования в конфигурационном файле приложения.
Для рейтинга необходимо создать отдельную модель привязанную к отдельной
таблице в базе данных, в которой создать методы для получения рейтинга
определенного набора данных по ID, также метод для установки нового рейтинга.
Пересчитывать рейтинг всех данных необходимо по cron-заданию, раз в 5 минут.
Работа с модераторским кабинетом
Система модерирования также является значительной частью конъюнктуры
приложения. С одной стороны, она является надстройкой над описанной ранее RBACсистемой, с другой - продолжением системы работы с файлами и редакциями.
Система должна использовать внутреннее API системы работы с файлами и
расширять модуль пользовательской системы.
Модераторский кабинет должен использовать функционал RBAC-системы, а также
быть жестко привязанным к первоначальным ее ролевым настройкам, произведенным
через административный интерфейс, поставляемый системой.
Работа с модулем Struct
Данный модуль должен быть ядром системы. Большинство разделов сайта (любые
разделы, связанные с хранением изменяемых данных и человеко-ориентированным
выводом) так или иначе будут использовать предоставляемую модулем систему.
Модуль Struct должен предоставлять систему хранения материалов, разбитых по
иерархическим категориям; внутреннее API поиска, сортировки и фильтров; а также
административный сервис управления категориями и материалами.
Соответствует
Соответствует
Соответствует
Соответствует
21
21.1
22
22.1
С помощь модуля Struct будут реализованы следующие функциональные части
проекта:
 Разделение сайта по разделам;
 Отображение меню и подменю с разделами;
 Разделы - статические страницы;
 Разделы с перечислением материалов (новости, файлы);
 Разделы, используемые как сокеты для контролеров под задачу (например, файлы).
Статистика
Необходимо предусмотреть в панели управления администратора возможность
просматривать статистику использования портала.
Внести в ее функционал следующее: количество подключений по API,
пользовательское голосование. С возможностью выбора диапазона дат отображения
статистических данных и фильтра по набору данных.
API
API портала необходимо для работы сторонних разработчиков с данными,
расположенными на портале. Оно должно быть реализовано по принципу RESTful. API
открытое, без логина. Будет доступно по адресу /api/[модель данных]. Все параметры
передаются http-методом POST.
Результатом будет вложенный массив данных в формате «xml» либо «json». Данные
находятся под ключом response. При всех ответах передается timestamp ответа.
Стандартные параметры:
action - действие, под текущей моделью
responseType - формат, в котором будет выдан результат (json, xml)
Модели данных:
news – Новости
files – Файлы
URL: /api/news
Параметры:
action:
default – вывод списка новостей
limit – количество новостей
offset – отступ
Соответствует
Соответствует
Соответствует
Соответствует
item – вывести данные по определенной новости
id – ID новости
fields – необходимые поля новости, доступные поля: date_display (дата новости),
title (заголовок), preview_pic (картинка-превью), short_text (текст описания), url (urlадрес новости), full_text (полный текст новости)
23
23.1
URL: /api/files
Параметры:
action:
getDatechange – вывод списка новостей
limit – количество новостей
offset – отступ
getFiles – вывести файлы, привязанные к актуальной версии набору данных
extension (необязательный параметр, если не установлен - выводятся все
форматы) – формат (расширение) файла, напр.: html, txt, xml.
id – ID набора файлов
В случае ошибки в ответе будет передан ее код (errorCode) и текст (errorText).
Технические требования к изменениям, вносимым в систему
Структура приложения
Структура приложения и логика взаимодействия между составными частями
приложения должны соответствовать принципам, положенным в основу проекта:
 Четкое соблюдение принципов МВК: разделение модель/контролер/представление;
 Группировка общих свойств и методов в компоненты;
 Вынесение основных настроек в конфигурацию; использование иерархической
конфигурации.
Соответствует
 Новые явные разделы должны быть привязаны к системе управления разделами
(модуль Struct)
 Изменение логики поведения разделов (категорий) реализуются за счет прикрепления
новых контролеров/модулей.
 Управление новыми модулями, а также любыми частями приложения должно
выноситься в административные сервисы, которые будут инкапсулированы в
административную систему (см. раздел «Интеграция с модулей административными
системами»).
Соответствует
24
24.1
25
25.1
26
26.1
27
27.1
28
28.1
 Никакие изменения поведения/вывода любых частей приложения, вне конъюнктуры
приложения не должны изменяться на месте («хардкодом»). Должны использоваться
соответствующие средства переопределения - иерархические конфигурации и
переопределение представлений.
 Каждый контролер, а также специфичные действия контролеров (например,
действия, изменяющие данные) должны иметь собственную RBAC-операцию. Для
каждой RBAC-операции должны быть проставлены права.
 Добавление клиент-ресурсов (JS/CSS) должно происходить через соответствующие
инструменты управления ресурсами.
 Должно использоваться кэширование с зависимостью.
Функциональные требования к мобильным приложениям
Потенциальный поставщик в рамках проекта должен разработать 2 приложения для
Соответствует
мобильных устройств на платформах IOS и Android соответственно.
Получение данных
Данные должны передаваться с портала открытых данных для каталогов,
предоставленных Заказчиком. Исходные данные с портала должны быть представлены в
Соответствует
XML-формате и содержать информацию для перечисленных выше типов организаций:
название, координаты, контакты.
Обработка данных
Полученные XML-документы должны предварительно обрабатываться скриптом
парсинга, нормализовываться и записываться в базу.
Соответствует
Для каждого документа (организации) должна быть одна категория в базе.
Каждая категория должна иметь уникальное название и id.
Обращение к системе
Серверная часть, обслуживающая приложение, должна представлять собой RESTful
веб-сервис. Обращение к системе должно осуществляться по открытому HTTPпротоколу с передачей параметров посредством GET.
Данные, запрашиваемые клиентом должны включать в себя обязательные параметры
Соответствует
(тип запроса, категория, геокоординаты устройства, данные для постраничной
навигации) и необязательные (строка поиска по точному совпадению содержимого дополнительный фильтр для каталога организаций).
Организация поиска
Поиск должен представлять собой дополнительный параметр фильтрации для
Соответствует
Соответствует
Соответствует
Соответствует
Соответствует
Соответствует
29
29.1
30
30.1
31
31.1
32
32.1
33
33.1
определенной категории (списка организаций). Также клиентское приложение должно
передавать геоданные (широта, долгота), на основании которых осуществляется
сортировка каталога (списка организаций).
Выдача данных
Сервер должен возвращать JSON-объект с отсортированными данными по удалению
от исходной позиции, по геокоординатам и по релевантности соответствия строке
поиска, если таковая задана.
Требования к поддержке языков
Государственный портал открытых данных должен поддерживать возможность
отображения контентных страниц на следующих языках:
 казахский;
 русский;
 английский.
Требования к документации
В рамках разработки и внедрения Государственного портала открытых данных.
Потенциальным поставщиком должна быть разработана следующая документация:
 Техническое задание.
 План-график проекта.
 Инструкция пользователя.
 Инструкция администратора.
Требования к обучению
Потенциальный
поставщик
должен
провести
обучение
пользователей
Государственного портала открытых данных в следующем количестве:
Пользователь (сотрудник Заказчика, осуществляющий модерацию портала) – не
менее 3 (три).
Администратор (сотрудник Заказчика, осуществляющий администрирование
портала) – не менее 2 (два).
Требования к срокам оказания услуг
Потенциальный поставщик должен обеспечить разработку и внедрение
Государственного портала открытых данных в срок не позднее 14 календарных дней с
момента заключения договора.
Соответствует
Соответствует
Соответствует
Соответствует
Соответствует
Соответствует
Соответствует
Соответствует
Соответствует
Соответствует
Требования к лицензионному программному обеспечению
Потенциальный поставщик должен гарантировать передачу Заказчику бессрочных
прав на использование разработанного и поставляемого в рамках проекта программного
Соответствует
обеспечения.
35
Требования к гарантийному обслуживанию
35.1
Потенциальный поставщик должен обеспечить следующий режим гарантийного
обслуживания разработанного и внедренного Портала:
Гарантийный период должен составлять 3 месяца с даты подписания Акта оказанных
услуг по разработке и внедрению Государственного портала открытых данных.
Соответствует
В объемы гарантийного обслуживания должно входить устранение всех сбоев и
ошибок в работе Государственного портала открытых данных.
Обслуживание в течение гарантийного периода должно выполняться Потенциальным
поставщиком на безвозмездной основе.
36
Требования к выполняемым работам
36.1
Работы по созданию портала открытых данных выполняются в 1 этап:
Работы (2013 год) включают в себя:
 Разработка технического задания на разработку Портала и утверждение его у
Заказчика;
 Разработка дизайн-концепции Портала;
 Разработка Портала, включающего следующие подсистемы:
Соответствует
 подсистема информационного взаимодействия с источниками открытых данных
и хранения открытых данных;
 подсистема классификации и поиска;
 подсистема коллективной работы и обсуждения;
 подсистема администрирования;
 Разработка проектной и эксплуатационной документации портала открытых данных;
 Проведение испытаний Портала.
36.1.1
Разработка технического задания на создание Портала
Исполнитель разрабатывает детализированное техническое задание на разработку
Портала.
Разработка Технического задания должна производиться в соответствии с
Соответствует
требованиями СТ РК 34.015-2002
«Техническое задание на создание
автоматизированной системы».
34
34.1
Соответствует
Соответствует
Соответствует
Соответствует
Разработка дизайн-концепции Портала
Исполнитель должен разработать не более 3 (трех) вариантов дизайн-концепции
Портала.
В состав вариантов дизайн-концепции Портала, разрабатываемых Исполнителем
должны обязательно входить:
 Дизайн-макет главной страницы портала (3 варианта дизайна);
 Дизайн-макеты страниц подсистемы информационного взаимодействия с
источниками открытых данных и хранения открытых данных (1 вариант дизайна);
Соответствует
 Дизайн-макеты страниц подсистемы коллективной работы и обсуждения (1 вариант
дизайна);
Дизайн сайта должен быть выполнен с учетом использования языка HTML и CSS.
Все страницы Портала должны корректно отображаться в современных браузерах
Microsoft Internet Explorer 9.0 и выше, Mozilla FireFox 22 и выше, Opera 10.0 и выше,
Google Chrome, Safari 5.1.7 и выше.
Также разработанный дизайн должен быть адаптирован в целях корректного
отображения страниц, элементов и функций Портала на мобильных устройствах.
36.1.3
Разработка Портала
Исполнитель должен разработать программное обеспечение Портала в соответствии
Соответствует
с требованиями, установленными и разработанном техническом задании.
36.1.4
Разработка проектной и эксплуатационной документации портала открытых данных
Проектная и эксплуатационная документация на Портал (далее – документы на
Портал) должна быть разработана в следующем составе:
 Описание автоматизируемых функций;
 Описание программного обеспечения;
 Описание информационного обеспечения;
Соответствует
 Ведомость машинных носителей информации;
 Руководство пользователя;
 Руководство администратора.
Эксплуатационная и проектная документация должна удовлетворять требованиям
ГОСТ 34.601-90 и РД 50-34.698-90.
36.1.5
Проведение испытаний Портала
Перед проведением испытаний должна быть разработана Программа и Методика
Соответствует
испытаний, предусматривающая проверку выполнения всех функций Системы.
36.1.2
Соответствует
Соответствует
Соответствует
Соответствует
37
37.1
38
38.1
Программа и Методика испытаний должна быть разработана в соответствии с
индивидуальными особенностями Системы, а также требований конкурсной
документации.
Программа и методика испытаний должна включать:
 Перечень объектов, выделенных в Системе для испытаний и перечень требований,
которым соответствуют объекты (со ссылкой на пункты ТЗ);
 Критерии приемки Системы и ее частей;
 Условия и сроки проведения испытаний;
 Средства для проведения испытаний;
 Фамилии лиц, ответственных за проведение испытаний;
 Методику испытаний и обработки их результатов;
 Перечень оформляемой документации.
На основании данной документации должны проводиться испытания Портала.
После разработки Программы и методики испытаний должны быть проведены
предварительные испытания Портала открытых данных.
Проверка функционирования должна быть направлена на определение соответствия
функционала Системы требованиям, предъявляемым в разработанном ТЗ.
После испытания Системы должен быть составлен протокол предварительных
испытаний, в котором будут учтены все недостатки Системы, которые необходимо
исправить, чтобы обеспечить соответствие Системы всем заявленным требованиям.
Работа завершается оформлением акта предварительных испытаний и готовности
системы для передачи в опытную эксплуатацию.
Требования к публикации данных о проекте
Потенциальный поставщик должен быть готов по запросу заказчика (в случае
необходимости) в первые 6 месяцев после запуска проекта обеспечить публикацию
Соответствует
данных о проекте в следующих печатных изданиях: Financial Times, New York Times,
РБК Daily.
Консультационная поддержка пользователей Портала
Консультационные
услуги
должны
предоставляться
Пользователям
и
Администраторам (сотрудникам Заказчика, осуществляющим модерацию и
администрирование портала). Консультационные услуги должны представляться по
Соответствует
всем вопросам, касающимся работы Портала.
Должны быть выделены следующие виды консультационных отзывов:
Соответствует
Соответствует




39
39.1
Вопрос;
Предложение;
Проблема;
Запрос на опубликование данных.
После поступления отзыва от пользователя сотрудник консультационной службы
должен иметь возможность:
 определить область вопроса данного отзыва (категорировать);
 определить какие действия подходят под эту область (типизировать);
 оценить уровень качества, который можно предоставить по данному вопросу; а также
действия для решения этого вопроса.
Этап проводимых работ
 Техническое задание на разработку Портала;
 Дизайн-концепция Портала, включающая:
 Дизайн-макет главной страницы портала (3 варианта дизайна);
 Дизайн-макеты страниц подсистемы информационного взаимодействия с
источниками открытых данных и хранения открытых данных (1 вариант
дизайна);
 Дизайн-макеты страниц подсистемы коллективной работы и обсуждения (1
вариант дизайна);
 Дизайн-макеты страниц информационно-аналитической подсистемы (1 вариант
дизайна).
 Дистрибутив и исходные коды портала;
 Проектная и эксплуатационная документация Портала:
 Описание автоматизируемых функций;
 Описание программного обеспечения;
 Описание информационного обеспечения;
 Ведомость машинных носителей информации;
 Руководство пользователя;
 Руководство администратора.
 Программа и Методика испытаний;
 Протокол проведения предварительных испытаний;
 Акт о завершении предварительных испытаний.
Соответствует
Соответствует
Выводы
1.
Предложения ТОО «Zero Gravity» и ТОО «Prime Source» соответствуют требованиям тендерной документации.
Разработчик Проектного офиса
Хасанов Р.Н.
Разработчик Проектного офиса
Бекбауов Е.А.