Методические рекомендации по практическому применению Свода стандартизованных спецификаций

	УТВЕРЖДАЮ
Директор Департамента государственного регулирования в экономике Минэкономразвития России	Исполнительный директор
______________	__________
«___» ____________ 2006 г.	«___» _____________2006 г.

Проект

Методические рекомендации по практическому применению Свода стандартизованных спецификаций

Листов: 9

Версия 1.0 от "15" ноября 2006 г.

СОГЛАСОВАНО	СОГЛАСОВАНО
От Заказчика	От Исполнителя
Советник Департамента государственного регулирования в экономике Минэкономразвития России	Руководитель проектов Департамента комплексных проектов
_________________	_____________________

СОДЕРЖАНИЕ

1 Введение Общие принципы        3

1.1 Проблемы и предпосылки        3

1.2 Принятые цели и вытекающие из них принципы        3

2 механизм реализации        6

2.1 Нормативно правовая конструкция        6

2.2 Обновление Свода        6

2.3 Использование заказчиком        6

2.4 Использование разработчиками        6

3 Применение моделей        6

3.1 Применение эталонных моделей        6

3.2 Эталонная архитектурная модель текущей версии Свода        6

3.3 Частная модель системы        6

3.4 Комментарии к архитектурному разделу Свода        6

3.5 Правила определения типов взаимодействий        9

3.6 Правила определения сетевых сред        11

4 Часто встречающиеся вопросы и ответы на них        12

5 Глоссарий        14

Введение Общие принципы Проблемы и предпосылки

Оценивая мировой опыт в области развития «электронного государства», т. е. государства, активно использующего для реализации своих функций и предоставления услуг современные информационные технологии, можно выделить следующие основные тенденции:

Системы электронного государства ориентируются на взаимодействие. Выигрыш, даваемый использованием информационной системы, мгновенно сводится на нет, если для получения информации из смежного ведомства или даже другой информационной системы того же ведомства требуется ручной труд и бумажный документооборот. Основным средством для взаимодействия государства, граждан и бизнеса становится Интернет. Использование простых и все более доступных средств Интернета позволяет сделать пользование информационными ресурсами «электронного государства» действительно удобным и повсеместно распространенным.

Однако, анализируя ситуацию, складывающуюся с внедрением информационных технологий в органах государственной власти России приходится признать, что степень проникновение этих идей в реальную жизнь весьма низка низкой. Количество межведомственных автоматизированных взаимодействий стремится к нулю, а степень представленности государственных органов в Интернете пока еще находится на начальном уровне по классификации ООН (в основном – публикация информации о деятельности госорганов с минимальными возможностями обратной связи).

Не последнюю роль в этом сыграло отсутствие скоординированной политики в области унификации и стандартизации информационных взаимодействий. В то время, как ведущие страны мира уже давно развивают регулирование в области архитектуры и интерфейсов государственных информационных систем (для примера – eGIF в Великобритании, FEA в США, ), Россия до последнего времени сильно отставала по этому направлению административной реформы.

Принятие Концепции стандартизации программного обеспечения органов государственной власти и Свода стандартизованных спецификаций призвано ликвидировать это отставание и создать условия для построения в государстве развитого и эффективного информационного пространства.

Принятые цели и вытекающие из них принципы

Основными целеполагающими принципами, принятыми при разработке Концепции, являются:

Защита интересов граждан государства при использовании, что выражается в обеспечении равного и недискриминирующего доступа к ресурсам ЭГ. Защита интересов национальной безопасности, что выражается в предотвращении возможности утраты государством контроля над своими информационными ресурсами.

В качестве основной угрозы для вышеуказанных интересов рассматривается наличие в информационных системах закрытых технологий, т. е. технологий, находящегося под контролем ограниченного круга лиц (владельцев технологий).

Закрытость технологий может обеспечиваться:

де-факто, когда соответствующее знание о способах реализации технологии неизвестно никому, кроме владельцев технологии и не может быть воспроизведено без их участия («ноу-хау»). де-юре, когда использование технологии не возможно без согласия владельца (патентное и авторское право).

Нарушение интересов граждан с использованием закрытых технологий, как правило, выражается в том, что для получения доступа к государственным информационным ресурсам, гражданин должен вступить в навязанное соглашение с ограниченным кругом лиц – как правило, единственным поставщиком той или иной технологии. Зачастую ограничения на доступ связаны с юридическим запретом на самостоятельное воспроизводство технологии или в использовании свойств технологии, недоступных для других разработчиков.

Угроза для национальной безопасности со стороны закрытых технологий состоит главным образом в возможности блокирования или затруднения работы ресурса путем отказа от его поддержки. Недоступность спецификаций технологии также порождает зависимость государства от единственного поставщика и невозможность самостоятельного развития ресурса без участия или согласия владельца технологии.

Таким образом, с точки зрения целей концепции, закрытые технологии представляют опасность в основном в тех случаях, когда они используются для реализации взаимодействий различного уровня – как между отдельными компонентами одной системы, так и между различными системами. В связи с этим Концепция не запрещает использование закрытых технологий, как таковых (что невозможно ни по экономическим, ни по техническим причинам), а лишь ограничивает их использование в тех случаях, когда это противоречит основным целеполагающим принципам. Ограничение осуществляется путем стандартизации интерфейсов программного обеспечения, которое состоит из двух частей:

определении «критичных» интерфейсов, которые должны реализовываться с использованием открытых стандартов определении конкретных стандартов (стандартизованных спецификаций), которые должны использоваться для реализации этих интерфейсов.

Собственно разработка стандартов, как показывает международная практика, в рамках регулирования технологий для государственных информационных систем, неэффективна – рынок в условиях конкуренции предлагает более удачные и лучше поддержанные технологии, чем создаваемые в рамках госзаказа (при этом активное участие государства в открытой разработке стандартов не исключается, но в качестве равноправного игрока или независимого арбитра).

Таким образом, стандартизация в рамках Концепции подразумевает регулярное (циклическое) выполнение сложной исследовательской и инженерной работы, результатом которой является построение эталонной архитектурно-технологической модели государственной информационной системы (профиля стандартов). Такая работа, как показывает международная практика, не может быть выполнена силами одного государственного ведомства или структуры, а требует привлечения к ней широких кругов неангажированных профессионалов-экспертов в области IT.

В связи с этим первоочередной задачей Концепции является не определение перечня конкретных требований к интерфейсам и стандартам, а установление открытого регламента формирования такого перечня («Свода требований»), причем термин «открытый регламент» подразумевает не только открытость самого документа с его описанием, но и открытость процедур, выполняемых в соответствии с регламентом, т. е.:

Гласность на всех этапах. Возможность участия в процедурах на любом этапе любого гражданина или организации. Невозможность монополизации регламентных процедур как государством, так и любым иным субъектом (обеспечение конфликта интересов).

Технологии (стандарты), используемые для реализации определенных в модели интерфейсов, должны удовлетворять следующим требованиям (блокирующие критерии, несоответствие которым делают недопустимым спецификации в Свод):

Должны быть специфицированы (документированы), что блокирует использование для реализации критичных интерфейсов технологий, закрытых де-факто. Не должны предусматривать платежей за каждое использование или иных  ограничений на использование, что блокирует использование технологий, закрытых де-юре.

Определение конкретных стандартов (стандартизованных спецификаций) преследует также вторичные цели Концепции: обеспечение эффективности (в т. ч. экономической) и результативности применяемых технологий за счет соблюдения следующих квалифицирующих принципов:

Спецификация должна в наибольшей степени соответствовать задачам интерфейса и обеспечивать необходимую функциональность. Для интерфейсов должен быть определен минимально необходимый набор обязательных спецификаций, что исключает несовместимость систем в рамках одного интерфейса. Спецификация должна быть зрелой (поддержанной рынком) и перспективной (с достаточным прогнозируемым сроком жизни). Спецификация должна быть стабильной, широко распространенной и доступной. Отсюда вытекает предпочтение международным стандартам.

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

механизм реализации Нормативно правовая конструкция

Требования по стандартизации программного обеспечения устанавливаются

Обновление Свода Использование заказчиком Использование разработчиками Применение моделей Применение эталонных моделей

Свод спецификаций

Эталонная архитектурная модель текущей версии Свода Частная модель системы

Частная модель системы – это просто перечень всех типов интерфейсов, используемых в системе, и способов их реализации.

Взаимодействующие объекты	Интерфейсы	Среда передачи данных	Способы реализации интерфейса в системе
Компонент	Смежная система	Базовый тип взаимодействия	Способ передачи информации	Тип передаваемой информации
1	2	3	4	5	6	7

Комментарии к архитектурному разделу Свода

7. В качестве взаимодействующих объектов информационной системы рассматриваются компоненты и смежные системы.

Определение границ информационной системы, особенно системы открытой, развивающейся и активно взаимодействующей с окружающей информационной средой – достаточно сложная задача. Является ли межсетевой экран частью системы, если он поставляется отдельно от нее? Является ли вновь разработанный портлет, целиком реализующий некоторую управленческую функцию, но предназначенный для работы в составе ведомственного портала, частью этого портала или новой информационной системой, взаимодействующей со старой?

Во избежание произвольного толкования и манипулирования требованиями путем произвольного установления границ системы, архитектурная модель не делит взаимодействия на «внутренние» и «внешние» по отношению к системе. Требования по стандартизации могут быть установлены как для тех объектов, которые разработчик или заказчик посчитал нужным считать частью системы (т. е. компонентов системы), так и для тех, которые рассматриваются, как не относящиеся к ней (т. е. смежные системы). Во внимание принимаются только общие свойства объектов и взаимодействий, не зависящие о того, как определена их системная принадлежность.

Пример:

Взаимодействие между веб-сервером и браузером обычно рассматривается как «внешнее», т. к. браузер поставляется пользователям третьими лицами. Однако разработчик может, например, разработать собственную несовместимую версию браузера и рассматривать ее, как специфический клиент – часть системы. Однако это не освобождает его от необходимости документировать в модели взаимодействие между «проприетарным» браузером и веб-сервером.

8. Под компонентом понимается функционально целостная часть информационной системы (как правило – программа или программный комплекс), которая может использоваться отдельно от данной информационной системы, в том числе в составе иной информационной системы.

В качестве основного признака для выделения компонента принимается его переносимость, т. е. способность исполняться вне программной среды. При этом информационная зависимость компонента от рассматриваемой системы не должна приниматься во внимание – очевидно, что сервер приложений в традиционной трехзвенной архитектуре не может работать отдельно от СУБД, если там хранятся прикладные данные конкретной системы, однако при этом он может быть перенесен на другой сервер или версия самой СУБД может быть обновлена. Аналогично, специализированное клиентское приложение подачи налоговой декларации, использующее сертифицированный алгоритм шифрования, не имеет смысла использовать без доступа к принимающей стороне, т. к. ключ для дешифровки имеется только у соответствующего уполномоченного оператора. Однако само по себе приложение может инсталлироваться на любых компьютерах, удовлетворяющих определенным программно-техническим средствам, следовательно, должно рассматриваться, как отдельный компонент системы (или, по усмотрению проектировщика – как внешняя программа, т. е. смежная система).

В некоторых случаях выделение компонентов не столь очевидно (например, может ли считаться компонентом конкретный программный модуль – сценарий, портлет и т. п.), однако с точки зрения целей и задач Концепции на текущем этапе это не столь критично и может оставляться на усмотрение разработчика. Допускается

Компоненты информационной системы делятся на:

Внутренние – эксплуатируемые непосредственно владельцем системы или назначенным им оператором. Внешние – передаваемые для эксплуатации владельцам и операторам смежных систем.

Критичным с точки зрения целей Концепции являются в основном взаимодействия между внутренними и внешними компонентами. Использование закрытых протоколов, реализуемых только поставляемым в составе системы клиентом, ставит стороннего пользователя в нежелательную зависимость от поставщика. В связи с этим основным признаком компонента признаком классификации компонентов выбрана их отчуждаемость: передается ли данная программа для установки на «чужом» компьютере на условиях продажи, аренды, безвозмездного пользования. В качестве внешних компонентов должны рассматриваться и части системы, реализуемые в виде программно-аппаратных комплексов: например, криптографических модулей, плат шифрования и т. п.

Исключением является удаленный программный аппаратно-программный комплекс, который продолжает эксплуатироваться владельцем системы, т. е. сам компонент не передается, а, напротив, владелец системы арендует (или получает безвозмездно) у сторонней организации место для размещения компонента или вычислительные мощности для исполнения программного обеспечения системы. Примером «внутреннего» компонента такого рода может являться, например, сайт, размещенный на виртуальном хостинге, или выделенный сервер системы, установленный на коллективной технологической площадке (т. н. услуга коллокации).

В том случае, если система не делится на компоненты, то она вся рассматривается как один внутренний компонент.

10. Смежной системой является программный или программно-аппаратный комплекс, не являющийся частью рассматриваемой информационной системы, но осуществляющий с ней информационные взаимодействия, предусмотренные функциональными возможностями рассматриваемой системы.

Если система передает информацию куда-либо, кроме своих компонентов – это рассматривается, как взаимодействие со смежной системой (в т. ч. если другой стороной является, например, персональный компьютер интернет-пользователя)

11. Информационные системы, созданные для реализации полномочий одного государственного органа, являются ведомственными информационными системами.

Информационные системы, созданные для реализации полномочий нескольких государственных органов, являются межведомственными информационными системами.

Текущая версия Свода основное внимание уделяет межведомственным взаимодействиям, исходя из предположения, что о многих ведомствах уже вынужденно были разработаны собственные стандарты внутреннего взаимодействия.

15. Непосредственные взаимодействия между пользователями системы и системой (человеко-машинные интерфейсы) при построении частной модели информационной системы не рассматриваются. При необходимости такие взаимодействия должны интерпретироваться, как взаимодействия с компонентом или смежной системой, реализующими пользовательский интерфейс (АРМ, клиентское приложение и т. п.).

См. комментарий к п. 10

Правила определения типов взаимодействий

16. Взаимодействием считается любой акт передачи информации от одного взаимодействующего объекта другому вне зависимости от того, используется ли передаваемая информация непосредственно для реализации полномочий государственных органов (прикладная информация) или служит исключительно для технического обеспечения функционирования информационной системы (техническая информация).

При наличии в системе взаимодействий, при которых информация адресуется от одного взаимодействующего объекта сразу нескольким объектам (вещательные взаимодействия), такие взаимодействия рассматриваются как несколько отдельных взаимодействий между отправителем информации и каждым получателем информации.

На практике «реальные» вещательные взаимодействия реализуются сейчас только в рамках низкоуровневых аппаратных протоколов (например, Ethernet), которые Сводом пока не регламентируются. Для исключения разночтений и упрощения модели все прочие взаимодействия сводятся к схеме «точка-точка». Например, при массовой почтовой рассылке в качестве взаимодействия рассматривается единичный акт доставки письма конкретному получателю.

17. Для каждого выявленного взаимодействия следует указать, к какому базовому типу оно относится. Базовые типы взаимодействий:

Сетевое синхронное взаимодействие – взаимодействие, осуществляемое по каналам связи, при котором ожидается обязательное получение непосредственной реакции со стороны вызываемого объекта и выполнение функции информационной системы может быть продолжено только после ее получения. Под непосредственной реакцией при этом понимается совершение действия по обработке или передаче прикладной информации.

Данный тип является основным и наиболее распространенным в современных сетях. Примером таких взаимодействий является доступ к страницам веб-интерфейса, когда на каждый HTTP-запрос должен быть получен немедленный адекватный HTTP-ответ, являющийся результатом интерпретации полученного запроса (аварийные ситуации здесь не рассматриваются, во внимание принимается только базовая функциональность системы). Под «немедленным» в данном случае понимается ответ, ожидаемый в пределах четко определенного протоколом взаимодействия временного промежутка (тайм-аута), в течение которого взаимодействующие объекты поддерживают единый сеанс связи.

Сетевое асинхронное взаимодействие – взаимодействие, осуществляемое по каналам связи, при котором не предусматривается непосредственной реакции со стороны вызываемого объекта (за исключением подтверждения самого факта получения сообщения, в т. ч. с обеспечением гарантированной доставки).

Основным видом данного взаимодействия является связь по электронной почте или доставка мгновенных сообщений. Основным отличительным признаком асинхронного взаимодействия является отсутствие смысловой интерпретации запроса принимающей стороной в рамках текущего сеанса связи. Например, при отправке письма по электронной почте принимающая система проверяет только его формальную корректность и, в случае успеха, завершает связь, квитируя получение. Обработка информации, содержащейся в письме, происходит уже вне сеанса связи. При этом ни передающая, ни принимающая система с точки зрения протокола взаимодействия не обязуются повторить сеанс связи в конкретный промежуток времени – отправитель письма может вообще не обратиться за ответом, и это не является аварийной ситуацией протокола.

При определении асинхронных взаимодействий учитываются только их технологические характеристики. Не считается асинхронным взаимодействие, при котором отсрочка реакции со стороны анализируемой информационной системы обусловлена установленным порядком осуществления функций государственным органом, если соответствующая технологическая функция системы выполняется в синхронном режиме.

Данное положение не позволяет считать асинхронным такие взаимодействия, как, например, прием заявления через веб-интерфейс. Действительно, как правило, система документооборота не даст автоматической реакции по существу заявления. Например, если запрашивается государственная регистрация частного предпринимателя – то отказ или подтверждение регистрации производится только после рассмотрения представленных документов. Однако с технологической точки зрения система все же проинтерпретировала запрос по смыслу в пределах одного сеанса связи: отосланная в запросе информация была проверена, обработана, сохранена с определенным статусом, а пользователю был выдана веб-страница с подтверждением этого.

18. Сетевые взаимодействия (сетевое синхронное, сетевое асинхронное) классифицируются в зависимости от способа передачи информации:

Непосредственное взаимодействие предусматривает передачу информации предназначенной для немедленной обработки и интерпретации получателем. Файловое взаимодействие предусматривает передачу информации в виде файла, предназначенного для сохранения и дальнейшего использования получателем без преобразования формата, или формируемого/получаемого смежной системой вне рамок данного взаимодействия.

Хотя само понятие «файл» может интерпретироваться неоднозначно, для определения файлового взаимодействия существенны только его прикладные свойства. HTML-документ, хотя и представляет собой файл, не предназначен для сохранения пользователем для последующей обработки: как правило, он интерпретируется сразу после получения и отображается на экране. Техническая возможность сохранения любой информации, получаемой в ходе компьютерных взаимодействий в данном случае не существенна, так как свод определяет условия только тех взаимодействий, которые осуществляются при функционировании системы, т. е. исполнении ею предусмотренных разработчиком функций (см. определение понятия «интерфейс»). Возможность совершения каких-либо не предусмотренных действий – как допустимых (сохранение не предназначенного для этого файла), так и недопустимых (передача информации в процессе хакерской атаки) – не относится к предмету рассмотрения Свода.

Потоковое взаимодействие предусматривает передачу информации в виде непрерывной последовательности данных неопределенной длительности, получение которой может быть начато и прекращено получателем в любой момент времени.

Пример потокового взаимодействия - «живое» телевизионное вещание (IP-телевидение), «голосовые чаты», IP-телефония и т. п. Несмотря на то, что принимающая сторона может сохранить полученный поток данных в виде файла, ей не гарантируется получение всего потока целиком.

19. Для файловых и потоковых взаимодействий должна быть дополнительно определена технологическая характеристика (тип) передаваемой информации. Перечень типов информации для соответствующих типов взаимодействий приводится в Технологическом разделе Свода.

Данный шаг предполагает обращение к технологическому разделу Свода, однако в процессе подготовки модели описание типов передаваемой информации может быть дано неформализовано: уточнение требований к типам данных производится уже на заключительной стадии, при рассмотрении требований к данному типу взаимодействий в целом. Например, для электронного архива веб-интерфейс просмотра фотоматериалов может быть определён, как «непосредственное синхронное взаимодействие, черно-белые полутоновые изображения». При уточнении обязательных спецификаций подбирается подходящая формулировка свода: «растровые изображения, допускающие (или не допускающие) потери качества при компрессии». В то же время использование неформализованного описания не может применяться для выведение данного взаимодействия из под требований Свода. Разработчик модели или проверяющий обязаны подобрать формальное определение, покрывающее неформальное, или, если это не удается – использовать спецификацию, определенную для «прочих типов данных» в рамках данного взаимодействия.

Как правило, технологическим разделом нормируется представление текстовых документов (в т. ч. включающих таблицы, разметку, рисунки и т. п.), а также мультимедийной информации – растровой и векторной графики, фонограмм (аудиофайлов), аудиовизуальных произведений (оцифрованного видео).

21. Взаимодействия между каждой парой объектов объединяются в группы с совпадающим набором характеристик (по базовому типу, способу передачи информации, типу передаваемых данных, наличию дополнительной характеристики) далее рассматриваются как один тип взаимодействия (интерфейс).

Данное правило позволяет обойтись без перечисления всех однотипных интерфейсов. Например, если система взаимодействует с двумя разными системами, принадлежащими другому ведомству, то описывается только один класс интерфейсов: «компонент (или система в целом)» - «смежная вневедомственная система».

Правила определения сетевых сред

24. Если в Технологическом разделе Свода установлено требование по обязательному использованию определенной сетевой среды или каналов связи для определенного типа взаимодействия, то реализация указанного типа взаимодействия может осуществляться только с использованием указанной сетевой среды. Если указание на обязательность использования определенной сетевой среды отсутствует, то реализация данного типа взаимодействия осуществляется с использованием любой сетевой среды.

Как правило, такое требование устанавливается для организации взаимодействия с системами граждан и организаций через Интернет и позволяет избежать внедрения нерациональных, дорогих и неудобных для пользователя решений типа организации модемных пулов и т. п.

25. При использовании информационной системой какой-либо сетевой среды передачи данных должна обеспечиваться поддержка всех спецификаций и инфраструктурных взаимодействий, определяемых оператором (управляющим или координирующим органом) соответствующей среды передачи данных.

Данное формальное положение позволяет избежать перегрузки свода тривиальной информацией и избавляет разработчиков систем от необходимости детализировать очевидные взаимодействия, без которых он в любом случае не сможет реализовать требуемое взаимодействие в рамках некоторой сетевой среды. Кроме того, это позволяет снизить затраты на приемку систем и проверку соответствия. Так, например, для выявления отсутствие корректной поддержки в Интернет-системе протокола резолюции доменных имен (DNS) не требуется каких-то специальных испытаний – некорректная адресация будет выявлена в ходе любого функционального теста, причем неработоспособность системы будет очевидна и для неспециалиста. В то же время наличие формального требования соблюдения подобных стандартов позволяет обоснованно отказать в приемке системы.

Часто встречающиеся вопросы и ответы на них

Регламентирует ли Свод внутреннюю архитектуру программ и систем?

Свод в принципе не использует понятие «граница системы» для определения требований по стандартизации. Понятия «внутренний» и «внешний» для компонентов определяются не по отношению к системе, а по отношению к владельцу системы. Свод также не устанавливает способов реализации компонентов систем, состава и правил сочетания внутренних и внешних компонентов и т. п. Однако Свод может устанавливать требования по применению стандартов взаимодействия между определенными видами компонентов, с этой точки зрения накладывая некоторые ограничения

В текущей версии Свода требования по взаимодействию между внутренними (не отчуждаемыми) компонентами системы не установлены.

С целью обеспечения соответствия Своду мы добавили к системе веб-интерфейс для администрирования персоналом системы и веб-сервис, через который можно получить пресс-релиз о вводе системы в действие. Таким образом, система поддерживает установленные сводом спецификации HTML, SOAP и др. Является ли она теперь соответствующей?

Нет, если другие интерфейсы подпадают под требования Свода, но реализованы нестандартно.

Запрещает ли Свод использование формата N?

Нет. Свод не устанавливает запретов на применение спецификаций, а только требования к обязательному их применению. Указание спецификации в качестве выбывающей или выбывшей служит, в частности, для определения потребностей в миграции систем, однако даже выбывшие спецификации можно продолжать использовать в качестве дополнения к основным, предусмотренным сводом, если этого желают обе взаимодействующие стороны.

Можем ли мы предложить формат N для включения в Свод?

Да, в соответствии с регламентом обновления Свода. Предлагаемый формат должен соответствовать всем основным требованиям (документированность, отсутствие ограничений) и превосходить другие предложенные для данного взаимодействия по квалифицирующим признакам.

Внутреннее устройство нашего формата полностью раскрыто в ходе обсуждений на веб-форуме для разработчиков. Можем ли мы указать ссылку на него в качестве спецификации?

Форум, как и любой другой динамический способ представления данных (новостная лента, база знаний) не может считаться спецификацией, т. к. не обеспечивает требования документированности, т. е. обеспечения неизменности содержания во времени.

В качестве спецификации может рассматриваться официально опубликованный «слепок» динамического ресурса. Однако в этом случае он должен соответствовать требованиям по полноте и достаточности, т. е., среди прочего не содержать умолчаний, ссылок на недокументированные ресурсы, противоречий в определения требований и т. п.

Будут ли в Своде устанавливаться требования к языкам программирования?

Свод регламентирует только требования к взаимодействиям. В то же время в мире современных технологий в некоторых случаях трудно провести границу между языком программирования и форматом файла, используемого в некотором стеке взаимодействия. Например, текущей версией Сводом регламентируется язык описания трансформаций данных (XSLT) и язык загружаемых сценариев (Java Script), которые могут рассматриваться как достаточно мощные языки программирования специального назначения. Однако включение в Свод полных спецификаций классических универсальных языков программирования типа C, Basic и т. п. не прогнозируется.

Интерфейсы на базе веб-сервисов неэффективны при передаче больших массивов данных. Можем ли мы в обоснованных случаях использовать другие спецификации?

Другие спецификации можно использовать в любых случаях и без дополнительных обоснований с точки зрения соответствия Своду. Однако параллельно должно быть соблюдено требование о реализации гарантированного доступа по стандартизованным протоколам.

Некоторые пользователи нашей системы живут в отдаленных деревнях с плохими каналами связи, пользуются устаревшими компьютерами и не могут использовать ресурсоемкие технологии, предлагаемые Сводом.

Наконец, текущая версия свода не исключает использование для взаимодействия машинных носителей. Традиционный метод представления данных «на дискете» пока что является объективно необходимым, хотя и в этом случае

Мы разработали мощный веб-интерфейс с применением концепции Web 2.0, технологии Ajax и уникальной запатентованной нами технологии сжатия растровых изображений. Для того чтобы работать с этим интерфейсом, достаточно установить последнюю версию браузера N. Если делать систему в рамках требований Свода, она станет менее удобной.

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

Браузер N 1.0. в любом случае не поддерживает даже тот набор спецификаций, что предусмотрен в Своде.

Введение регулирования не ставит целью реализацию идей абсолютного равенства программных средств. Программы и технологии выбывают из обращения и их вечная поддержка невозможна. Кроме того, электронное взаимодействие в любом случае Целью Свода является установление минимально необходимых требований, соответствующих сегодняшнему уровню технологий и в то же время доступных большинству пользователей.

Глоссарий

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

Информационное взаимодействие – событие передачи любой информации между компонентами информационной системы или между информационными системами.

Базовая функциональность информационной системы – совокупность юридически значимых функций, которые реализуются или обеспечиваются данной информационной системой, а также функций доступа граждан и организаций в соответствии с законом к содержащейся в системе информации.

Государственная информационная система – информационная система, созданная или используемая в целях реализации полномочий государственных органов, обеспечения обмена информацией между государственными органами, между государственными органами и гражданами и организациями, а также в иных установленных федеральными законами целях.

Пользователь информационной системы – лицо, участвующее в функционировании автоматизированной системы или использующее результаты ее функционирования;

Интерфейс – граница между информационными системами или их компонентами, через которую в процессе функционирования системы осуществляются информационные взаимодействия.

Заказчик системы - организация, которая приобретает или получает систему, программный продукт или программную услугу от поставщика.

Владелец системы – организация, устанавливающая порядок применения и эксплуатация системы.

Оператор системы– организация, непосредственно эксплуатирующая систему.

Файл – снабженная идентификатором совокупность данных на машинном носителе, организованная в соответствии с определенными правилами (форматом файла) и имеющая известный в каждый момент времени размер.

Протокол – совокупность правил организации информационных взаимодействий определенного типа.

Формат – совокупность правил кодирования и упорядочивания информации определенного типа.