Отчет о нир листов
| Вид материала | Отчет |
- Отчет нии экспериментальной медицины сзо рамн о выполнении плана нир за 2009г и план, 29.72kb.
- Отчет о научно-исследовательской работе за 2007 год Тема нир: Разработка и создание, 107.74kb.
- Отчет о научно-исследовательской работе за 2007 год Тема нир: Разработка новых радиоволновых, 53.72kb.
- Отчет о научно-исследовательской работе за 2008 год Тема нир: Разработка новых радиоволновых, 49.86kb.
- Отчет о научно-исследовательской работе за 2008 год Тема нир: Исследование новых механизмов, 65.37kb.
- Лексикология для высших учебных заведений1[1], 2831.98kb.
- Отчет о научной деятельности Сибирского государственного индустриального университета, 292.94kb.
- Р. И. об итогах нир университета за 2009 год на Ученом совете от 8 февраля 2010 год, 887.59kb.
- Отчет о нир/окр (бумажная версия) (наименование отчета), 45.75kb.
- Отчет по нир, 650.93kb.
.2Направление работ 4. Разработка варианта регулирования для использования в рамках Минэкономразвития россии.
Для начальной стадии внедрения Концепции СПО в рамках проекта был разработан комплект документов, регламентирующих использование Концепции при осуществлении закупок в рамках госконтрактов, заключаемых Минэкономразвития России. В указанный комплект включены:
- Проект положения о временной технической комиссии Минэкономразвития России (Приложение 9).
- Проект регламента работы временной технической комиссии Минэкономразвития России (Приложение 10).
Предложенная выше нормативно-правовая конструкция исключает необходимость промежуточного этапа ее внедрения, т.е. создания временной технической комиссии уровня Министерства. Тем не менее разработанный документ может применяться в качестве методического источника при разработке аналогичных по смыслу нормативно-правовых конструкций а также в случае, если введение предложенного регулирования в предполагаемые по плану сроки окажется невозможным.
.3Направление работ 5. Разработка проектов организационных документов
Организационные документы СПО определяют различные аспекты, связанные с участием граждан и организаций в открытых процедурах принятия Свода стандартизованных спецификаций и сопутствующих ему документов. Проекты нижеперечисленных документов приведены в Приложениях 11 – 21.
Регламенты и положения, утверждаемые решениями Правительственной комиссии по админреформе:
- Положение о конфликтной комиссии. Определяет статус, полномочия и область компетенции конфликтной комиссии. Конфликтную комиссию предлагается создать, как межведомственный консультативный орган, выполняющий функции независимого арбитра при рассмотрении жалоб на нарушения регламентов открытых процедур разработки проекта СПО, подразумевающих участие определяемого по Госконтракту исполнителя работ, МИТС РФ, экспертов, а также граждан и организаций, принимающих участие в общественных обсуждениях.
- Регламент работы конфликтной комиссии. Определяет порядок приема и рассмотрения жалоб на нарушения регламентов.
Регламенты и положения, утверждаемые приказами МИТС РФ:
- Положение об экспертах. Устанавливает квалификационные и иные требования к экспертам, меры по обеспечению независимости и непредвзятости.
- Регламент работы экспертных групп. Определяет порядок формирования и работы групп экспертов, осуществляющих независимую оценку спецификаций, предложенных для включения в Свод.
- Регламент разработки и принятия локальных профилей СПО. Локальные профили в рамках новой нормативной конструкции отнесены к методическому обеспечению и являются рекомендательными документами, упрощающими реализацию требований Свода.
- Регламент ведения реестра выбывших спецификаций. Определяет порядок включения спецификаций в список окончательно выбывших, статус включенных в список спецификаций, порядок разрешения конфликтов и проблем.
- Регламент раскрытия рабочих материалов СПО. Определяет состав внутренних материалов, связанных с разработкой Свода и иных оргметодических документов, подлежащих обязательному раскрытию, сроки и порядок публикации.
- Регламент организации общественных обсуждений. Определяют порядок организации обсуждения тех документов и разделов Концепции СПО, для которых он не установлен отдельным регламентом.
- Инструкция по документообороту в рамках регламентов СПО. Определяет требования к оформлению проектов нормативных актов, разрабатываемых
- Инструкция по взаимодействию через Интернет. Определяет порядок регистрации участников регламентов СПО в информационной системе СПО и передачи документов через Интернет с использованием ИС СПО.
- Редакционная политика сайта ТК. Определяет состав публикуемых материалов (помимо установленных иными регламентами), требования к штатным и внештатным сотрудникам и авторам), структуру и порядок изменения тематических рубрикаторов сайта ТК, периодичность публикации материалов, общие требования к содержанию и качеству редакционных материалов.
Создание методического обеспечения
.1Направление 1. Методические рекомендации по применению Концепции СПО
Концепция и Свод являются нормативно-техническими документами, в связи с чем в них используются понятия и формулировки, сложные для восприятия неподготовленным пользователем (разработчики ПО, не имеющие необходимых юридических знаний, и, напротив, должностные лица ОГВ, не имеющие специального технического образования). Настоящий раздел содержит указания и разъяснения по применению положений наиболее сложных для восприятия элементов концепции, а также ответы на наиболее часто встречающиеся вопросы, зафиксированные в ходе семинаров и общественных обсуждений, проводившихся в рамках реализации работ.
.1.1Применение эталонной модели
В настоящем подразделе содержатся комментарии к тексту архитектурного раздела Свода (дан курсивом), поясняющие порядок его использования для составления частной модели информационной системы при ее декларировании или проектировании.
7. В качестве взаимодействующих объектов информационной системы рассматриваются компоненты и смежные системы.
Определение границ информационной системы, особенно системы открытой, развивающейся и активно взаимодействующей с окружающей информационной средой – достаточно сложная задача. Является ли межсетевой экран частью системы, если он поставляется отдельно от нее? Является ли вновь разработанный портлет, целиком реализующий некоторую управленческую функцию, но предназначенный для работы в составе ведомственного портала, частью этого портала или новой информационной системой, взаимодействующей со старой?
Во избежание произвольного толкования и манипулирования требованиями путем произвольного установления границ системы, архитектурная модель не делит взаимодействия на «внутренние» и «внешние» по отношению к системе. Требования по стандартизации могут быть установлены как для тех объектов, которые разработчик или заказчик посчитал нужным считать частью системы (т.е. компонентов системы), так и для тех, которые рассматриваются, как не относящиеся к ней (т.е. смежные системы). Во внимание принимаются только общие свойства объектов и взаимодействий, не зависящие о того, как определена их системная принадлежность.
Пример:
Взаимодействие между веб-сервером и браузером обычно рассматривается как «внешнее», т.к. браузер поставляется пользователям третьими лицами. Однако разработчик может, например, разработать собственную несовместимую версию браузера и рассматривать ее, как специфический клиент – часть системы. Однако это не освобождает его от необходимости документировать в модели взаимодействие между «проприетарным» браузером и веб-сервером.
8. Под компонентом понимается функционально целостная часть информационной системы (как правило – программа или программный комплекс), которая может использоваться отдельно от данной информационной системы, в том числе в составе иной информационной системы.
В качестве основного признака для выделения компонента принимается его переносимость, т.е. способность исполняться вне программной среды. При этом информационная зависимость компонента от рассматриваемой системы не должна приниматься во внимание – очевидно, что сервер приложений в традиционной трехзвенной архитектуре не может работать отдельно от СУБД, если там хранятся прикладные данные конкретной системы, однако при этом он может быть перенесен на другой сервер или версия самой СУБД может быть обновлена. Аналогично, специализированное клиентское приложение подачи налоговой декларации, использующее сертифицированный алгоритм шифрования, не имеет смысла использовать без доступа к принимающей стороне, т.к. ключ для дешифровки имеется только у соответствующего уполномоченного оператора. Однако само по себе приложение может инсталлироваться на любых компьютерах, удовлетворяющих определенным программно-техническим средствам, следовательно, должно рассматриваться, как отдельный компонент системы (или, по усмотрению проектировщика – как внешняя программа, т.е. смежная система).
В некоторых случаях выделение компонентов не столь очевидно (например, может ли считаться компонентом конкретный программный модуль – сценарий, портлет и т.п.), однако с точки зрения целей и задач Концепции на текущем этапе это не столь критично и может оставляться на усмотрение разработчика. Допускается
Компоненты информационной системы делятся на:
- Внутренние – эксплуатируемые непосредственно владельцем системы или назначенным им оператором.
- Внешние – передаваемые для эксплуатации владельцам и операторам смежных систем.
Критичным с точки зрения целей Концепции являются в основном взаимодействия между внутренними и внешними компонентами. Использование закрытых протоколов, реализуемых только поставляемым в составе системы клиентом, ставит стороннего пользователя в нежелательную зависимость от поставщика. В связи с этим основным признаком компонента признаком классификации компонентов выбрана их отчуждаемость: передается ли данная программа для установки на «чужом» компьютере на условиях продажи, аренды, безвозмездного пользования. В качестве внешних компонентов должны рассматриваться и части системы, реализуемые в виде программно-аппаратных комплексов: например, криптографических модулей, плат шифрования и т.п.
Исключением является удаленный программный аппаратно-программный комплекс, который продолжает эксплуатироваться владельцем системы, т.е. сам компонент не передается, а, напротив, владелец системы арендует (или получает безвозмездно) у сторонней организации место для размещения компонента или вычислительные мощности для исполнения программного обеспечения системы. Примером «внутреннего» компонента такого рода может являться, например, сайт, размещенный на виртуальном хостинге, или выделенный сервер системы, установленный на коллективной технологической площадке (т.н. услуга коллокации).
В том случае, если система не делится на компоненты, то она вся рассматривается как один внутренний компонент.
10. Смежной системой является программный или программно-аппаратный комплекс, не являющийся частью рассматриваемой информационной системы, но осуществляющий с ней информационные взаимодействия, предусмотренные функциональными возможностями рассматриваемой системы.
Если система передает информацию куда-либо, кроме своих компонентов – это рассматривается, как взаимодействие со смежной системой (в т.ч. если другой стороной является, например, персональный компьютер интернет-пользователя)
11. Информационные системы, созданные для реализации полномочий одного государственного органа, являются ведомственными информационными системами.
Информационные системы, созданные для реализации полномочий нескольких государственных органов, являются межведомственными информационными системами.
Текущая версия Свода основное внимание уделяет межведомственным взаимодействиям, исходя из предположения, что о многих ведомствах уже вынужденно были разработаны собственные стандарты внутреннего взаимодействия.
15. Непосредственные взаимодействия между пользователями системы и системой (человеко-машинные интерфейсы) при построении частной модели информационной системы не рассматриваются. При необходимости такие взаимодействия должны интерпретироваться, как взаимодействия с компонентом или смежной системой, реализующими пользовательский интерфейс (АРМ, клиентское приложение и т.п.).
См. комментарий к п. 10
16. Взаимодействием считается любой акт передачи информации от одного взаимодействующего объекта другому вне зависимости от того, используется ли передаваемая информация непосредственно для реализации полномочий государственных органов (прикладная информация) или служит исключительно для технического обеспечения функционирования информационной системы (техническая информация).
При наличии в системе взаимодействий, при которых информация адресуется от одного взаимодействующего объекта сразу нескольким объектам (вещательные взаимодействия), такие взаимодействия рассматриваются как несколько отдельных взаимодействий между отправителем информации и каждым получателем информации.
На практике «реальные» вещательные взаимодействия реализуются сейчас только в рамках низкоуровневых аппаратных протоколов (например, Ethernet), которые Сводом пока не регламентируются. Для исключения разночтений и упрощения модели все прочие взаимодействия сводятся к схеме «точка-точка». Например, при массовой почтовой рассылке в качестве взаимодействия рассматривается единичный акт доставки письма конкретному получателю.
17. Для каждого выявленного взаимодействия следует указать, к какому базовому типу оно относится. Базовые типы взаимодействий:
- Сетевое синхронное взаимодействие – взаимодействие, осуществляемое по каналам связи, при котором ожидается обязательное получение непосредственной реакции со стороны вызываемого объекта и выполнение функции информационной системы может быть продолжено только после ее получения. Под непосредственной реакцией при этом понимается совершение действия по обработке или передаче прикладной информации.
Данный тип является основным и наиболее распространенным в современных сетях. Примером таких взаимодействий является доступ к страницам веб-интерфейса, когда на каждый HTTP-запрос должен быть получен немедленный адекватный HTTP-ответ, являющийся результатом интерпретации полученного запроса (аварийные ситуации здесь не рассматриваются, во внимание принимается только базовая функциональность системы). Под «немедленным» в данном случае понимается ответ, ожидаемый в пределах четко определенного протоколом взаимодействия временного промежутка (тайм-аута), в течение которого взаимодействующие объекты поддерживают единый сеанс связи.
- Сетевое асинхронное взаимодействие – взаимодействие, осуществляемое по каналам связи, при котором не предусматривается непосредственной реакции со стороны вызываемого объекта (за исключением подтверждения самого факта получения сообщения, в т.ч. с обеспечением гарантированной доставки).
Основным видом данного взаимодействия является связь по электронной почте или доставка мгновенных сообщений. Основным отличительным признаком асинхронного взаимодействия является отсутствие смысловой интерпретации запроса принимающей стороной в рамках текущего сеанса связи. Например, при отправке письма по электронной почте принимающая система проверяет только его формальную корректность и, в случае успеха, завершает связь, квитируя получение. Обработка информации, содержащейся в письме, происходит уже вне сеанса связи. При этом ни передающая, ни принимающая система с точки зрения протокола взаимодействия не обязуются повторить сеанс связи в конкретный промежуток времени – отправитель письма может вообще не обратиться за ответом, и это не является аварийной ситуацией протокола.
При определении асинхронных взаимодействий учитываются только их технологические характеристики. Не считается асинхронным взаимодействие, при котором отсрочка реакции со стороны анализируемой информационной системы обусловлена установленным порядком осуществления функций государственным органом, если соответствующая технологическая функция системы выполняется в синхронном режиме.
Данное положение не позволяет считать асинхронным такие взаимодействия, как, например, прием заявления через веб-интерфейс. Действительно, как правило, система документооборота не даст автоматической реакции по существу заявления. Например, если запрашивается государственная регистрация частного предпринимателя – то отказ или подтверждение регистрации производится только после рассмотрения представленных документов. Однако с технологической точки зрения система все же проинтерпретировала запрос по смыслу в пределах одного сеанса связи: отосланная в запросе информация была проверена, обработана, сохранена с определенным статусом, а пользователю был выдана веб-страница с подтверждением этого.
18. Сетевые взаимодействия (сетевое синхронное, сетевое асинхронное) классифицируются в зависимости от способа передачи информации:
- Непосредственное взаимодействие предусматривает передачу информации предназначенной для немедленной обработки и интерпретации получателем.
- Файловое взаимодействие предусматривает передачу информации в виде файла, предназначенного для сохранения и дальнейшего использования получателем без преобразования формата, или формируемого/получаемого смежной системой вне рамок данного взаимодействия.
Хотя само понятие «файл» может интерпретироваться неоднозначно, для определения файлового взаимодействия существенны только его прикладные свойства. HTML-документ, хотя и представляет собой файл, не предназначен для сохранения пользователем для последующей обработки: как правило, он интерпретируется сразу после получения и отображается на экране. Техническая возможность сохранения любой информации, получаемой в ходе компьютерных взаимодействий в данном случае не существенна, так как свод определяет условия только тех взаимодействий, которые осуществляются при функционировании системы, т.е. исполнении ею предусмотренных разработчиком функций (см. определение понятия «интерфейс»). Возможность совершения каких-либо не предусмотренных действий – как допустимых (сохранение не предназначенного для этого файла), так и недопустимых (передача информации в процессе хакерской атаки) – не относится к предмету рассмотрения Свода.
- Потоковое взаимодействие предусматривает передачу информации в виде непрерывной последовательности данных неопределенной длительности, получение которой может быть начато и прекращено получателем в любой момент времени.
Пример потокового взаимодействия - «живое» телевизионное вещание (IP-телевидение), «голосовые чаты», IP-телефония и т.п. Несмотря на то, что принимающая сторона может сохранить полученный поток данных в виде файла, ей не гарантируется получение всего потока целиком.
19. Для файловых и потоковых взаимодействий должна быть дополнительно определена технологическая характеристика (тип) передаваемой информации. Перечень типов информации для соответствующих типов взаимодействий приводится в Технологическом разделе Свода.
Данный шаг предполагает обращение к технологическому разделу Свода, однако в процессе подготовки модели описание типов передаваемой информации может быть дано неформализовано: уточнение требований к типам данных производится уже на заключительной стадии, при рассмотрении требований к данному типу взаимодействий в целом. Например, для электронного архива веб-интерфейс просмотра фотоматериалов может быть определён, как «непосредственное синхронное взаимодействие, черно-белые полутоновые изображения». При уточнении обязательных спецификаций подбирается подходящая формулировка свода: «растровые изображения, допускающие (или не допускающие) потери качества при компрессии». В то же время использование неформализованного описания не может применяться для выведение данного взаимодействия из под требований Свода. Разработчик модели или проверяющий обязаны подобрать формальное определение, покрывающее неформальное, или, если это не удается – использовать спецификацию, определенную для «прочих типов данных» в рамках данного взаимодействия.
Как правило, технологическим разделом нормируется представление текстовых документов (в т.ч. включающих таблицы, разметку, рисунки и т.п.), а также мультимедийной информации – растровой и векторной графики, фонограмм (аудиофайлов), аудиовизуальных произведений (оцифрованного видео).
21. Взаимодействия между каждой парой объектов объединяются в группы с совпадающим набором характеристик (по базовому типу, способу передачи информации, типу передаваемых данных, наличию дополнительной характеристики) далее рассматриваются как один тип взаимодействия (интерфейс).
Данное правило позволяет обойтись без перечисления всех однотипных интерфейсов. Например, если система взаимодействует с двумя разными системами, принадлежащими другому ведомству, то описывается только один класс интерфейсов: «компонент (или система в целом)» - «смежная вневедомственная система».
24. Если в Технологическом разделе Свода установлено требование по обязательному использованию определенной сетевой среды или каналов связи для определенного типа взаимодействия, то реализация указанного типа взаимодействия может осуществляться только с использованием указанной сетевой среды. Если указание на обязательность использования определенной сетевой среды отсутствует, то реализация данного типа взаимодействия осуществляется с использованием любой сетевой среды.
Как правило, такое требование устанавливается для организации взаимодействия с системами граждан и организаций через Интернет и позволяет избежать внедрения нерациональных, дорогих и неудобных для пользователя решений типа организации модемных пулов и т.п.
25. При использовании информационной системой какой-либо сетевой среды передачи данных должна обеспечиваться поддержка всех спецификаций и инфраструктурных взаимодействий, определяемых оператором (управляющим или координирующим органом) соответствующей среды передачи данных.
Данное формальное положение позволяет избежать перегрузки свода тривиальной информацией и избавляет разработчиков систем от необходимости детализировать очевидные взаимодействия, без которых он в любом случае не сможет реализовать требуемое взаимодействие в рамках некоторой сетевой среды. Кроме того, это позволяет снизить затраты на приемку систем и проверку соответствия. Так, например, для выявления отсутствие корректной поддержки в Интернет-системе протокола резолюции доменных имен (DNS) не требуется каких-то специальных испытаний – некорректная адресация будет выявлена в ходе любого функционального теста, причем неработоспособность системы будет очевидна и для неспециалиста. В то же время наличие формального требования соблюдения подобных стандартов позволяет обоснованно отказать в приемке системы.
.1.2Часто встречающиеся вопросы и ответы на них
Регламентирует ли Свод внутреннюю архитектуру программ и систем?
Свод в принципе не использует понятие «граница системы» для определения требований по стандартизации. Понятия «внутренний» и «внешний» для компонентов определяются не по отношению к системе, а по отношению к владельцу системы. Свод также не устанавливает способов реализации компонентов систем, состава и правил сочетания внутренних и внешних компонентов и т.п. Однако Свод может устанавливать требования по применению стандартов взаимодействия между определенными видами компонентов, с этой точки зрения накладывая некоторые ограничения
В текущей версии Свода требования по взаимодействию между внутренними (не отчуждаемыми) компонентами системы не установлены.
С целью обеспечения соответствия Своду мы добавили к системе веб-интерфейс для администрирования персоналом системы и веб-сервис, через который можно получить пресс-релиз о вводе системы в действие. Таким образом, система поддерживает установленные сводом спецификации HTML, SOAP и др. Является ли она теперь соответствующей?
Нет, если другие интерфейсы подпадают под требования Свода, но реализованы нестандартно.
Запрещает ли Свод использование формата N?
Нет. Свод не устанавливает запретов на применение спецификаций, а только требования к обязательному их применению. Указание спецификации в качестве выбывающей или выбывшей служит, в частности, для определения потребностей в миграции систем, однако даже выбывшие спецификации можно продолжать использовать в качестве дополнения к основным, предусмотренным сводом, если этого желают обе взаимодействующие стороны.
Можем ли мы предложить формат N для включения в Свод?
Да, в соответствии с регламентом обновления Свода. Предлагаемый формат должен соответствовать всем основным требованиям (документированность, отсутствие ограничений) и превосходить другие предложенные для данного взаимодействия по квалифицирующим признакам.
Внутреннее устройство нашего формата полностью раскрыто в ходе обсуждений на веб-форуме для разработчиков. Можем ли мы указать ссылку на него в качестве спецификации?
Форум, как и любой другой динамический способ представления данных (новостная лента, база знаний) не может считаться спецификацией, т.к. не обеспечивает требования документированности, т.е. обеспечения неизменности содержания во времени.
В качестве спецификации может рассматриваться официально опубликованный «слепок» динамического ресурса. Однако в этом случае он должен соответствовать требованиям по полноте и достаточности, т.е., среди прочего не содержать умолчаний, ссылок на недокументированные ресурсы, противоречий в определения требований и т.п.
Будут ли в Своде устанавливаться требования к языкам программирования?
Свод регламентирует только требования к взаимодействиям. В то же время в мире современных технологий в некоторых случаях трудно провести границу между языком программирования и форматом файла, используемого в некотором стеке взаимодействия. Например, текущей версией Сводом регламентируется язык описания трансформаций данных (XSLT) и язык загружаемых сценариев (Java Script), которые могут рассматриваться как достаточно мощные языки программирования специального назначения. Однако включение в Свод полных спецификаций классических универсальных языков программирования типа C, Basic и т.п. не прогнозируется.
Интерфейсы на базе веб-сервисов неэффективны при передаче больших массивов данных. Можем ли мы в обоснованных случаях использовать другие спецификации?
Другие спецификации можно использовать в любых случаях и без дополнительных обоснований с точки зрения соответствия Своду. Однако параллельно должно быть соблюдено требование о реализации гарантированного доступа по стандартизованным протоколам.
Некоторые пользователи нашей системы живут в отдаленных деревнях с плохими каналами связи, пользуются устаревшими компьютерами и не могут использовать ресурсоемкие технологии, предлагаемые Сводом. Предлагаем включить в Свод более старые спецификации в качестве альтернативных.
Концепция ориентирована на построение соответствующего требованиям сегодняшнего дня информационного пространства. Поэтому включение в Свод устаревших спецификаций прямо противоречит целям Концепции и приведет к тому, что будет утрачена совместимость государственных систем.
Тем не менее Концепция учитывает необходимость поддержки взаимодействия с унаследованными системами. Это может быть реализовано с помощью локальных адаптеров, шлюзов и т.п. – более подробная информация приводится в документе «Требования по совместимости с унаследованными системами и поддержке выбывающих спецификаций. Правила миграции».
Наконец, текущая версия свода не исключает использование для взаимодействия машинных носителей. Традиционный метод представления данных «на дискете» пока что является объективно необходимым, хотя и в этом случае должны соблюдаться положения Свода об используемых форматах.
В нашем ведомстве применяется современная интеграционная платформа, которая обеспечивает успешное взаимодействие между системами внутри ведомства, но не соответствует требованиям Свода. Что делать?
В этом случае предусматривается возможность использования ведомственного шлюза. Как правило, его реализация позволит эксплуатировать унаследованные системы в течение всего предусмотренного проектом срока их применения. Однако вновь внедряемые системы должны обеспечивать поддержку Свода изначально, хотя это не исключает их совместимостью с другими используемыми в ведомстве стандартами взаимодействия. Некоторое дублирование интерфейсов, возникающее при этом, полностью окупается снижением затрат на обеспечение взаимодействия в будущем.
Мы разработали мощный веб-интерфейс с применением концепции Web 2.0, технологии Ajax и уникальной запатентованной нами технологии сжатия растровых изображений. Для того чтобы работать с этим интерфейсом, достаточно установить последнюю версию браузера N. Если делать систему в рамках требований Свода, она станет менее удобной.
Несмотря на это система должна обеспечивать работу в ограниченном режиме, позволяющей получить доступ к информационным ресурсам государства не только пользователям браузера N. В «совместимом» режиме должен обеспечиваться доступ ко всей базовой функциональности информационной системы, т.е. те функции, которые связаны с исполнением прав и обязанностей граждан, организаций и государственных органов.
Браузер N 1.0. в любом случае не поддерживает даже тот набор спецификаций, что предусмотрен в Своде.
Введение регулирования не ставит целью реализацию идей абсолютного равенства программных средств. Программы и технологии выбывают из обращения и их вечная поддержка невозможна. Кроме того, электронное взаимодействие в любом случае Целью Свода является установление минимально необходимых требований, соответствующих сегодняшнему уровню технологий и в то же время доступных большинству пользователей.