В соответствии с п. 2.3.3. Конкурсной документации Минэкономразвития России направляет разъяснения по запросу Участника размещения заказа:
Вопрос участника размещения заказа:
Одним из критериев оценки качества работ по части лотов является «Степень соответствия информационной системы, в том числе программного обеспечения, требованиям по стандартизации интерфейса указанных систем» (Таблица 2. Критерии и баллы оценки заявок для лотов ……). Оценка осуществляется по результатам заполнения формы 1.4.4.6., где указываются конкретные сведения о взаимодействии компонентов системы. Эти сведения могут быть получены в результате проектирования системы. Однако разработка данной системы начинается с разработки Концепции и ТЗ, где и формируются требуемые сведения. В связи с этим просим Вас разъяснить данное противоречие, а так же дополнительные разъяснения по заполнению формы 1.4.4.6.
Разъяснение: Основной задачей декларирования интерфейсов является повышение интероперабильности государственных информационных систем. С этой целью правилами конкурса в заведомо худшие условия ставятся системы с проприетарными и закрытыми интерфейсами. Задачей декларирования является в первую очередь подтверждение готовности Участника сохранять открытость и стандартность "внешних" интерфейсов поставляемых систем.
При декларировании Участником указываются только используемые стандарты и протоколы, но не описывается конкретная технология реализации соответствия (языки программирования, архитектура шлюза и т.п.). При этом требования по стандартизации не накладывают на Участников никаких дискриминирующих ограничений или блокирующих условий: все стандартизованные спецификации являются широко распространенными, открытыми, не предусматривают роялти и имеют достаточное количество альтернативных реализаций. Декларированию подлежат только "внешние" интерфейсы системы, а также интерфейсы между системой и ее отчуждаемыми компонентами. Связи между внутренними компонентами системы не регламентируются и декларируются только по усмотрению Участника. Не требуется также декларирование интерфейсов с внутриведомственными смежными системами в том случае, если технические требования предусматривают разработку нового программного обеспечения, как интегрированного компонента ранее внедренного. Не декларируются также интерфейсы с собственной программно-аппаратной платформой системы, в т.ч. ОС, системными библиотеками, межсетевыми экранами, СУБД (кроме случаев, когда СУБД представляет собой смежную систему) и т.п.
Согласно информационной карте эксперты оценивают полноту декларирования интерфейсов, исходя из имеющейся на данный момент проектно-технической документации, т.е. как с учетом представленной Участником методологии (которая должна подробно раскрывать предлагаемые решения поставленных в лоте задач), так и с учетом технических требований на лот.
Таким образом: в том случае, если задание лота предполагает создание информационной системы со стадии ТЗ или более поздней (по ГОСТ 34.601), то Участник уже располагает достаточной информацией для полного и достоверного декларирования, т.к. на данном этапе общая архитектура системы (наличие отчуждаемых компонентов и состав смежных систем) уже известны. В том случае, если Участник не может гарантировать, что он готов реализовать известный ему интерфейс установленным в требованиях по стандартизации способом - он должен отразить это в декларации, указав вместо наименования спецификации "не определено", и потеряв соответственно в оценке заявки. - В том случае, если задание лота начинается с концептуальной стадии (т.е. включает обследование объекта автоматизации и т.п. работы, предполагающие заведомо неполноту информации о задаче), то в декларации указываются известные на данный момент интерфейсы, на которые накладываются безусловные ограничения по стандартизации (например, для публичных портальных проектов очевидно наличие веб-интерфейса для граждан). В отношении интерфейсов со смежными системами делается оговорка о представлении детализированной (расширенной, но не измененной) декларации на стадии утверждения ТЗ и фиксируется заявление о готовности/не готовности обеспечить при разработке системы соответствие требованиям по стандартизации (в примечаниях к декларации). В том случае, если наличие интерфейса не следует прямо из конкурсной документации и заявки, то за недекларирование такого интерфейса оценка заявки снижаться не будет. В том случае, если задание лота включает только концептуальную стадию, то декларация не заполняется, в форме указывается, что непосредственная поставка информационной системы в рамках лота не производится и размещается заявление о том, что требования по стандартизации будут учтены и включены в проектную документацию, разрабатываемую по лоту.
Дополнительные разъяснения:
Разъяснения и указания по заполнению декларации
Пояснения к требованиям по стандартизации. Настоящий раздел не является частью требований по стандартизации системы, представляя собой методические рекомендации и пояснения к отдельным положениям требований (даны курсивом). В качестве взаимодействующих объектов информационной системы рассматриваются компоненты и смежные системы. Определение границ информационной системы, особенно системы открытой, развивающейся и активно взаимодействующей с окружающей информационной средой – достаточно сложная задача. Является ли межсетевой экран частью системы, если он поставляется отдельно от нее? Является ли вновь разработанный портлет, целиком реализующий некоторую управленческую функцию, но предназначенный для работы в составе ведомственного портала, частью этого портала или новой информационной системой, взаимодействующей со старой?
Во избежание произвольного толкования и манипулирования требованиями путем произвольного установления границ системы, в требованиях не содержится указаний на способ выделения компонентов по отношению к системе. Требования по стандартизации могут быть установлены как для тех объектов, которые разработчик или заказчик посчитал нужным считать частью системы (т.е. компонентов системы), так и для тех, которые рассматриваются, как не относящиеся к ней (т.е. смежные системы). Во внимание принимаются только общие свойства объектов и взаимодействий, не зависящие о того, как определена их системная принадлежность.
Пример:
Взаимодействие между веб-сервером и браузером обычно рассматривается как «внешнее», т.к. браузер поставляется пользователям третьими лицами. В то же время разработчик может, например, создать собственную несовместимую версию браузера и рассматривать ее, как специфический клиент – часть системы. Однако это не освобождает его от необходимости декларировать взаимодействие между «проприетарным» браузером и веб-сервером, поскольку компонент «браузер» передается для эксплуатации стороннему пользователю, не являющемуся владельцем или оператором системы. Под компонентом понимается функционально целостная часть информационной системы (как правило – программа или программный комплекс), которая может использоваться отдельно от данной информационной системы, в том числе в составе иной информационной системы.
В качестве основного признака для выделения компонента принимается его переносимость, т.е. способность исполняться вне программной среды. При этом информационная зависимость компонента от рассматриваемой системы не должна приниматься во внимание – очевидно, что сервер приложений в традиционной трехзвенной архитектуре не может работать отдельно от СУБД, если там хранятся прикладные данные конкретной системы, однако при этом он может быть перенесен на другой сервер или версия самой СУБД может быть обновлена. Аналогично, специализированное клиентское приложение подачи налоговой декларации, использующее сертифицированный алгоритм шифрования, не имеет смысла использовать без доступа к принимающей стороне, т.к. ключ для дешифровки имеется только у соответствующего уполномоченного оператора. Однако само по себе приложение может инсталлироваться на любых компьютерах, удовлетворяющих определенным программно-техническим средствам, следовательно, должно рассматриваться, как отдельный компонент системы (или, по усмотрению проектировщика – как внешняя программа, т.е. смежная система).
В некоторых случаях выделение компонентов не столь очевидно (например, может ли считаться компонентом конкретный программный модуль – сценарий, портлет и т.п.), однако с точки зрения целей и задач Концепции стандартизации на текущем этапе это не столь критично и может оставляться на усмотрение разработчика.
Компоненты информационной системы делятся на:
§ Внутренние – эксплуатируемые непосредственно владельцем системы или назначенным им оператором.
§ Внешние – передаваемые для эксплуатации владельцам и операторам смежных систем. Критичным с точки зрения целей стандартизации являются в основном взаимодействия между внутренними и внешними компонентами. Использование закрытых протоколов, реализуемых только поставляемым в составе системы клиентом, ставит стороннего пользователя в нежелательную зависимость от поставщика. В связи с этим основным признаком компонента признаком классификации компонентов выбрана их отчуждаемость: передается ли данная программа для установки на «чужом» компьютере на условиях продажи, аренды, безвозмездного пользования. В качестве внешних компонентов должны рассматриваться и части системы, реализуемые в виде программно-аппаратных комплексов: например, криптографических модулей, плат шифрования и т.п.
Исключением является удаленный программный аппаратно-программный комплекс, который продолжает эксплуатироваться владельцем системы, т.е. сам компонент не передается, а, напротив, владелец системы арендует (или получает безвозмездно) у сторонней организации место для размещения компонента или вычислительные мощности для исполнения программного обеспечения системы. Примером «внутреннего» компонента такого рода может являться сайт, размещенный на виртуальном хостинге, или выделенный сервер системы, установленный на коллективной технологической площадке.
В том случае, если система не делится на компоненты, то она вся рассматривается как один внутренний компонент.
Смежной системой является программный или программно-аппаратный комплекс, не являющийся частью рассматриваемой информационной системы, но осуществляющий с ней информационные взаимодействия, предусмотренные функциональными возможностями рассматриваемой системы.
Если система передает информацию куда-либо, кроме своих компонентов – это рассматривается, как взаимодействие со смежной системой (в т.ч. если другой стороной является, например, персональный компьютер интернет-пользователя).
Информационные системы, созданные для реализации полномочий одного государственного органа, являются ведомственными информационными системами.
Информационные системы, созданные для реализации полномочий нескольких государственных органов, являются межведомственными информационными системами.
Текущая версия Требований основное внимание уделяет межведомственным взаимодействиям, исходя из предположения, что о многих ведомствах уже вынужденно были разработаны собственные стандарты внутреннего взаимодействия.
Синхронное взаимодействие – взаимодействие, осуществляемое по каналам связи, при котором ожидается обязательное получение непосредственной реакции со стороны вызываемого объекта и выполнение функции информационной системы может быть продолжено только после ее получения.Под непосредственной реакцией при этом понимается совершение действия по обработке или передаче прикладной информации.
Данный тип является основным и наиболее распространенным в современных сетях. Примером таких взаимодействий является доступ к страницам веб-интерфейса, когда на каждый HTTP-запрос должен быть получен немедленный адекватный HTTP-ответ, являющийся результатом интерпретации полученного запроса (аварийные ситуации здесь не рассматриваются, во внимание принимается только базовая функциональность системы). Под «немедленным» в данном случае понимается ответ, ожидаемый в пределах четко определенного протоколом взаимодействия временного промежутка (тайм-аута), в течение которого взаимодействующие объекты поддерживают единый сеанс связи.
Асинхронное взаимодействие – взаимодействие, осуществляемое по каналам связи, при котором не предусматривается непосредственная реакция со стороны вызываемого объекта (за исключением подтверждения самого факта получения сообщения, в т.ч. с обеспечением гарантированной доставки).
Основным видом данного взаимодействия является связь по электронной почте или доставка мгновенных сообщений. Основным отличительным признаком асинхронного взаимодействия является отсутствие смысловой интерпретации запроса принимающей стороной в рамках текущего сеанса связи. Например, при отправке письма по электронной почте принимающая система проверяет только его формальную корректность и, в случае успеха, завершает связь, квитируя получение. Обработка информации, содержащейся в письме, происходит уже вне сеанса связи При этом ни передающая, ни принимающая система с точки зрения протокола взаимодействия не обязуются повторить сеанс связи в конкретный промежуток времени – отправитель письма может вообще не обратиться за ответом, и это не является аварийной ситуацией протокола.
При определении асинхронных взаимодействий учитываются только их технологические характеристики. Не считается асинхронным взаимодействие, при котором отсрочка реакции со стороны анализируемой информационной системы обусловлена установленным порядком осуществления функций государственным органом, если соответствующая технологическая функция системы выполняется в синхронном режиме.
Данное положение не позволяет считать асинхронным такие взаимодействия, как, например, прием заявления через веб-интерфейс. Действительно, как правило, система документооборота не даст автоматической реакции по существу заявления. Например, если запрашивается государственная регистрация частного предпринимателя – то отказ или подтверждение регистрации производится только после рассмотрения представленных документов. Однако с технологической точки зрения система все же проинтерпретировала запрос по смыслу в пределах одного сеанса связи: отосланная в запросе информация была проверена, обработана, сохранена с определенным статусом, а пользователю был выдана веб-страница с подтверждением этого.
Отдельно определяются «файловые» взаимодействия, при которых происходит передача ограниченного пакета информации определенного типа в установленном формате.
В общем случае файловое взаимодействие предусматривает передачу информации в виде файла, предназначенного для сохранения и дальнейшего использования получателем без преобразования формата, или формируемого/получаемого смежной системой вне рамок данного взаимодействия.
Как правило, в рамках файловых взаимодействий устанавливаются требования по представлению текстовых документов (в т.ч. включающих таблицы, разметку, рисунки и т.п.), а также мультимедийной информации – растровой и векторной графики, фонограмм (аудиофайлов), аудиовизуальных произведений (оцифрованного видео).
Требования по файловым взаимодействиям не распространяются на потоковую передачу информации, т.к. такое взаимодействие предусматривает передачу информации в виде непрерывной последовательности данных неопределенной длительности, получение которой может быть начато и прекращено получателем в любой момент времени.
Пример потокового взаимодействия - «живое» телевизионное вещание (IP-телевидение), «голосовые чаты», IP-телефония и т.п. Несмотря на то, что принимающая сторона может сохранить полученный поток данных в виде файла, ей не гарантируется получение всего потока целиком.
При использовании информационной системой какой-либо сетевой среды передачи данных должна обеспечиваться поддержка всех спецификаций и инфраструктурных взаимодействий, определяемых оператором (управляющим или координирующим органом) соответствующей среды передачи данных.
Данное формальное положение позволяет избежать перегрузки требований тривиальной информацией и избавляет разработчиков систем от необходимости детализировать очевидные взаимодействия, без которых он в любом случае не сможет реализовать требуемое взаимодействие в рамках некоторой сетевой среды. Кроме того, это позволяет снизить затраты на приемку систем и проверку соответствия. Так, например, для выявления отсутствие корректной поддержки в Интернет-системе протокола резолюции доменных имен (DNS) не требуется каких-то специальных испытаний – некорректная адресация будет выявлена в ходе любого функционального теста, причем неработоспособность системы будет очевидна и для неспециалиста. В то же время наличие формального требования соблюдения подобных стандартов позволяет обоснованно отказать в приемке системы.
Часто встречающиеся вопросы и ответы на них.
Регламентируют ли Требования внутреннюю архитектуру программ и систем?
Требования в принципе не использует понятие «граница системы» для определения требований по стандартизации. Понятия «внутренний» и «внешний» для компонентов определяются не по отношению к системе, а по отношению к владельцу системы.
Требования также не устанавливают способов реализации компонентов систем, состава и правил сочетания внутренних и внешних компонентов и т.п.
С целью обеспечения соответствия требованиям мы добавили к системе веб-интерфейс для администрирования системы и веб-сервис, через который можно получить пресс-релиз о вводе системы в действие. Таким образом, система поддерживает установленные требованиями по стандартизации спецификации HTML, SOAP и др. Является ли она теперь соответствующей?
Нет, если другие интерфейсы подпадают под требования, но реализованы нестандартно.
Запрещается ли Требованиями использование формата N?
Нет. Требования не устанавливают запретов на применение спецификаций, а только требования к обязательному их применению. Указание спецификации в качестве выбывающей или выбывшей служит, в частности, для определения потребностей в миграции систем, однако даже выбывшие спецификации можно продолжать использовать в качестве дополнения к обязательным, если это оговорено требованиями к системе.
Внутреннее устройство нашего формата полностью раскрыто в ходе обсуждений на веб-форуме для разработчиков. Можем ли мы указать ссылку на него в качестве спецификации?
Форум, как и любой другой динамический способ представления данных (новостная лента, база знаний) не может считаться спецификацией, т.к. не обеспечивает требования документированности, т.е. обеспечения неизменности содержания во времени.
В качестве спецификации может рассматриваться официально опубликованный «слепок» динамического ресурса. Однако в этом случае он должен соответствовать требованиям по полноте и достаточности, т.е., среди прочего не содержать умолчаний, ссылок на недокументированные ресурсы, противоречий в определения требований и т.п.
Интерфейсы на базе веб-сервисов неэффективны при передаче больших массивов данных. Можем ли мы в обоснованных случаях использовать другие спецификации?
Другие спецификации при наличии обоснованной необходимости можно использовать в любых случаях. Однако параллельно должно быть соблюдено требование о реализации гарантированного доступа к тем же данным и функциям по стандартизованным протоколам. Некоторые пользователи нашей системы живут в отдаленных деревнях с плохими каналами связи, пользуются устаревшими компьютерами и не могут использовать ресурсоемкие технологии. Можем ли мы в связи с этим отказаться от применения ресурсоемкой обязательной спецификации X?
Концепция стандартизации программного обеспечения ориентирована на построение соответствующего требованиям сегодняшнего дня информационного пространства.
При этом требования по стандартизации допускают использование любых технологий и спецификаций, в т.ч. и в целях обеспечения совместимости с унаследованными системами – но только при условии поддержки и обязательных спецификаций.
Наконец, текущая версия требований не исключает использование для взаимодействия машинных носителей. Традиционный метод представления данных «на дискете» пока что является объективно необходимым, хотя и в этом случае должны соблюдаться требования по стандартизации используемых форматов.
Мы разработали (планируем разработать) мощный веб-интерфейс с применением концепции Web 2.0, технологии Ajax и уникальной запатентованной нами технологии сжатия растровых изображений. Для того чтобы работать с этим интерфейсом, достаточно установить последнюю версию браузера N. Если делать систему в рамках требований по стандартизации, она станет менее удобной.
Несмотря на это система должна обеспечивать работу и в режиме «ограниченного сервиса», позволяющем получить доступ к информационным ресурсам государства не только пользователям браузера N. В «совместимом» режиме должен обеспечиваться доступ ко всей базовой функциональности информационной системы, т.е. те функции, которые связаны с исполнением прав и обязанностей граждан, организаций и государственных органов.
Браузер N версии 1.0. в любом случае не поддерживает даже тот набор спецификаций, что предусмотрен требованиями по стандартизации.
Введение стандартизации не ставит целью реализацию идей абсолютного равенства программных средств. Программы и технологии выбывают из обращения и их вечная поддержка невозможна. Целью стандартизации является установление минимально необходимых требований, соответствующих сегодняшнему уровню технологий и в то же время доступных большинству пользователей.
