Реферат: Реферат объем документа

ЗАО "ЛАНИТ"


















СТАНДАРТИЗАЦИЯ программного обеспечения




Версия 0.5

Редакция 24.08.05













2005



РЕФЕРАТ

Объем документа:

Страниц - . Таблиц – 4. Иллюстраций – 3. Приложение – 1.

Ключевые слова:

СТАНДАРТИЗАЦИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, ЭЛЕКТРОННОЕ ГОСУДАРСТВО, СТАНДАРТИЗАЦИЯ, ПРОФИЛЬ СТАНДАРТОВ, СТАНДАРТИЗОВАННЫЕ СПЕЦИФИКАЦИИ, ИНТЕГРАЦИЯ ПРОГРАММ, ОТКРЫТАЯ СИСТЕМА, ОТКРЫТЫЙ СТАНДАРТ, ЖИЗНЕННЫЙ ЦИКЛ СТАНДАРТА.

^ Текст реферата:

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

Документ включает описание:

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

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

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

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

Принципов проектирования и разработки программных систем, включая: открытость стандартов (п. 1.2.1.2), возможность межпрограммного взаимодействия (пп. 1.2.2.1-1.2.2.3, 4.2.-4.3, интеграция с унаследованными системами – 1.2.4), защищенность, масштабируемость, устойчивость, доступность и др. (раздел 4, в частности, п. 4.4).

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

Содержание

1 общие сведения 5

.1.1 Предмет документа 5

.1.2 Основополагающие принципы 5

.1.2.1 Область регулирования 5

.1.2.2 Определение технологических подходов 6

.1.2.2.1. Использование специфицированных интерфейсов 6

.1.2.2.2. Использование метаязыка представления данных 7

.1.2.2.3. Сопровождение метаданными 7

.1.2.2.4. Браузер, как универсальный клиент 7

.1.2.3 Определение соответствия систем требованиям СПО 8

.1.2.4 Поддержка унаследованных систем 9

.1.2.4.1. Определение минимального уровня совместимости. 9

.1.2.4.2. Использование посредников 10

.1.2.4.3. Миграция 11

2 Использование стандартов. единая Система профилей 12

.2.1 Предпосылки 12

.2.1.1 Общие вопросы унификации архитектурных решений 12

.2.1.1.1. Проблемы и вызовы 12

.2.1.1.2. Определение целей и задач 13

.2.1.1.3. Определение базовых подходов 13

.2.1.2 Определение базовых понятий стандартизации СПО 14

.2.1.2.1. Стандарты и спецификации 14

.2.1.2.2. Стандарты де-факто 15

.2.1.3 Профили 16

.2.2 Структура Главного профиля стандартизованных спецификаций 18

.2.2.1 Архитектурный уровень 20

.2.2.2 Функциональный уровень 20

.2.2.3 Локальный уровень 21

.2.3 Принципы выбора спецификаций 21

.2.3.1 Требования 21

.2.3.2 Приоритеты 22

.2.4 Жизненные циклы 24

.2.4.1 Жизненный цикл Главного профиля 24

.2.4.2 Жизненный цикл стандартизованных спецификаций 25

.2.5 Переводы 28

3 Архитектурная модель 29

.3.1 Использование эталонных моделей 29

.3.2 Базовая функциональная модель ODP-RM 31

4 Архитектурные требования и рекомендации 33

.4.1 Организационная точка зрения 33

.4.1.1 Юридические механизмы 33

.4.1.2 Уровни внешнего взаимодействия 33

.4.2 Информационная точка зрения 35

.4.2.1 Использование метаязыка 35

.4.2.2 Метаданные 35

.4.3 Компонентная точка зрения 37

.4.4 Инженерная точка зрения 38

.4.5 Технологическая точка зрения 39


^ 1общие сведения .1.1Предмет документа
Настоящий документ описывает архитектуру программного обеспечения (СПО) – комплекс взаимоувязанных решений по основополагающим принципам выбора технологий для создания программ в информационных системах электронного госудраства (ЭГ), интеграции информационных систем ЭГ, а также требований к необходимым для разработки и функционирования этих программ техническим средствам и иным видам обеспечения.
^ .1.2Основополагающие принципы
Современному электронному правительству требуются способные к взаимодействию информационные и коммуникационные системы, которые (в идеальном случае) прозрачно интегрируются друг с другом. Возможность взаимодействия (интеграции) информационных и коммуникационных систем может быть достигнута за счёт использования однозначно определенных стандартов и спецификаций. СПО определяет необходимые стандарты, форматы и спецификации, устанавливает для них правила соответствия и обновляет их с учётом инноваций в области высоких технологий.

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

создании (проектировании, разработке, внедрении) и интеграции новых информационных систем электронного государства;

интеграции унаследованных информационных систем, разработанных до принятия СПО;

организации и поддержке информационного взаимодействия субъектов электронного государства.

Определения по разделу:

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

Субъект электронного государства – физическое или юридическое лицо (равно как иная юридически определенная организационная структура), являющееся участником государственных административных процессов и использующая для этого информационно-коммуникационные технологии в рамках институтов электронного государства.
^ .1.2.2Определение технологических подходов .1.2.2.1.Использование специфицированных интерфейсов
Как минимум все внешние интерфейсы информационных систем электронного государства (то есть интерфейсы, через которые осуществляется взаимодействие с внешними пользователями и смежными информационными системами других владельцев), должны быть описаны с использованием формализованных в СПО методик. При реализации интерфейсов должны в обязательном порядке использоваться средства, методы и технологии, установленные в СПО для соответствующего круга задач, при этом допускается использование расширений и дополнений, не противоречащих базовой спецификации. Такие расширения и дополнения также должны быть документированы.

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

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

Определения по разделу:

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

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

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

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

В случае если для какой-либо ранее внедренной информационной системы ЭГ уже было разработано и опубликовано описание какого-либо типа данных на метаязыке, и оно удовлетворяет функциональным требованиям к вновь создаваемой системе, её разработчики должны отдавать предпочтение существующему формату.
^ .1.2.2.3.Сопровождение метаданными
В основу взаимодействия систем электронного государства должен быть положен обмен учетными объектами, то есть целостных совокупностей первичных учетных данных (как правило, электронных документов), снабженных отчуждаемыми метаописаниями (совокупностями вторичных учетных данных), используемыми для поиска, обработки и каталогизации (определения использованных в настоящем разделе понятий области учета данных см. в документе «Концепция государственного учета»).
^ .1.2.2.4.Браузер, как универсальный клиент
Использование браузера в качестве универсального клиента
приложений электронного государства ставит своей целью предоставление равных возможностей доступа граждан к возможностям электронного государства.

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

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

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

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

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

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

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

применением стандартизированных компонентных, функциональных и процессных моделей;

применением стандартизированных моделей данных при взаимодействии с другими информационными системами;

применением стандартизованных в СПО технических спецификаций;

использованием уже существующих в системах ЭГ самостоятельных компонентов;

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

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

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

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

Определения по разделу:

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

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

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

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

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

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

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

СПО определяет следующие способы реализации программ посредников:

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

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

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

Вопросы определения оптимальных процедур миграции в данной версии СПО отнесены к будущему развитию документа.
^ 2Использование стандартов. единая Система профилей .2.1Предпосылки .2.1.1Общие вопросы унификации архитектурных решений .2.1.1.1.Проблемы и вызовы
Практика реализации программы “Электронная Россия” показала, что государственные ведомства сталкиваются со значительными трудностями при принятии решений по выбору конкретных продуктов из большого числа существующих технологий и стандартов, способов поддержания сотрудничества с другими государственными органами, по организации эффективного обмена данными. Отсутствие согласованной политики в области коммуникационных протоколов и форматов данных приводит к тому, что для каждого вновь возникающего случая, когда необходимо организовать взаимодействие двух ведомственных систем, создается уникальное и не пригодное для других ситуаций интерфейсное решение. Общее количество таких решений в результате становится равным количеству связей между ведомствами.

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

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

Все эти факторы приводят к неэффективному расходованию государственных средств и повышению инвестиционных рисков.

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

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

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

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

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

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

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

пригодность с учётом меняющихся требований в отношении объёмов и частоты транзакций (масштабируемость);

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

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

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

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

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

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

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

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

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

Таблица 2.1.

Обозначение

Наименование

^ Официальный интернет-ресурс

ISO

International Organization for Standartization

http://iso.org/

ГОСТ Р

Национальная система стандартов Российской Федерации.




IETF

The Internet Engineering Task Force

http://www.ietf.org/

W3C

World Wide Web Consortium

http://www.w3.org/

OASIS

Organization for the Advancement of Structured Information Standards

http://www.oasis-open.org/



Определения по разделу:

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

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

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

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

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

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

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

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



В свою очередь государственные заказчики должны с осторожностью относиться к финансированию разработки