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

	Архитектура программного обеспечения
	Версия 0.5 Редакция 24.08.05
	2005

РЕФЕРАТ

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

Страниц - 39. Таблиц – 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 32

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. Браузер, как универсальный клиент

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

Пример 1:

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

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

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

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

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

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. Стандарты де-факто

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

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

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

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

Пример 2:

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

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

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

2.1.3 Профили

Задачи выбора унифицированных решений в области АПО имеет следующие отличия от задач стандартизации в традиционном понимании этого термина:

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

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

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

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

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

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

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

Хотя профиль в определенной степени может рассматриваться, как разновидность стандарта (так, в русском переводе международного стандарта ГОСТ Р ИСО/МЭК ТО 10000-1 вместо термина “профиль” предпочитается термин “функциональный стандарт”), в целях более четкого разграничения понятий в рамках АПО процедура профилирования рассматривается как задача, отличная от задачи стандартизации.

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

· Необходимость увязки спецификации с функциями АПО.

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

· Необходимость учета проблем наследования и миграции.

· Необходимость более высокого темпа обновления профилей для обеспечения соответствия АПО современным требованиям.

· Необходимость более мягкой политики по отношению к «нормативным нестыковкам» спецификаций в связи с необходимостью увязки в одном профиле.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· Локальный уровень, состав которого отражается в основном документе (Главном профиле) в виде перечня действующих локальных профилей.

Взаимоотношения между базовыми уровнями и их отображение на пространство спецификаций показано на рисунке. Более подробно каждый из уровней рассмотрен в подразделах 2.2.1-2.2.3

Рис. 2.1.

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

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

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

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

Стандартизованная спецификация АПО – спецификация, включенная в Главный профиль АПО (каталог спецификаций АПО).

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

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

сочетания (стеки) спецификаций.

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

Задачей архитектурного уровня Главного профиля АПО является обеспечение сопоставимых с общепринятой международной практикой методов формирования и толкования функциональной модели.

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

Более подробно подходы к формированию архитектурного уровня Главного профиля и АПО в целом описаны в разделе Архитектурная модель настоящего документа.

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

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

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

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

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

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

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

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

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

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

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

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

2.3.1 Требования

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

Детализированный перечень требований к спецификации таков:

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

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

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

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

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

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

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

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

2.3.2 Приоритеты

Не все из критериев пригодности спецификации для решения задач АПО могут быть определены достаточно строго и дискретно («пригодна/не пригодна»). В их отношении можно вести речь только об определении некоторых приоритетов и предпочтений, которые должны отдаваться при отборе спецификаций для профиля. К их числу относятся:

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

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

· Соответствие содержания спецификации отечественным нормативным актам и действующим нормативным и руководящим документам в области АПО и электронного государства в целом.

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

· Ориентация спецификации на открытые системы.

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

· Признание спецификации в других системах электронного государства. Спецификация должна быть формально или фактически принята в сходных областях государственных информационных систем за рубежом. В качестве основных справочных документов при анализе данного фактора рекомендуется использовать SAGA (ФРГ), TSC eGIF (Великобритания), FEA TRM (США).

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

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

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

· Достаточность рыночной поддержки. На рынке должно быть представлено достаточное количество качественных и востребованных реализаций данной спецификации.

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

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

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

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

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

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

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

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

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

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

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

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

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

Процедура принятия новой версии Главного профиля носит циклический характер и состоит из двух этапов:

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

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

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

Взаимосвязь всех жизненных циклов, связанных с Главным профилем, показана на Рис. 2.2:

Рис. 2.2.

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

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

Схематично этот поток представлен на рисунке 2.3:

Рис. 2.3.

Место спецификации в «потоке развития» описывается с помощью следующих базовых статусов:

· Обязательная. Данная спецификация рекомендуется к указанию в функциональной модели Главного профиля АПО в качестве основной.

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

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

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

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

Формальные статусы, предусматриваемые для Главного профиля, перечислены в таблице.

Таблица 2.2.

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

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

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

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

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

Реестр выбывших спецификаций – официальный документ, содержащий перечень устаревших или не удовлетворяющих основополагающим принципам АПО спецификаций. Документ носит справочно-рекомендательный характер и публикуется на сайте ТК. Порядок ведения реестра определяется отдельным регламентом ТК.

2.5 Переводы

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

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

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

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

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

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

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

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

Основными задачами создания архитектурной модели ПО электронного государства являются:

· Совместимость на уровне функций, административных процессов: общие методы описания, общие принципы выполнения операций и принятия решений, единое понимание логики процессов.

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

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

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

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

Таблица 3.3.

Наименование эталонной модели				Обозначение	Спецификация
модель	подмодель
Эталонная модель для открытой распределенной обработки.				ODP RM	ITU-T Rec. 902|ISO/IEC 10746-2:1995, Reference Model for Open Distributed Processing – Reference Model: Foundation. ITU-T Rec. 903|ISO/IEC 10746-3:1995, Reference Model for Open Distributed Processing – Reference Model: Architecture Спецификации ITU-T серии X.900
Язык спецификации интерфейсов объектов			ODP IDL	ISO/IEC DIS 14750:1999, Information technology – Open Distributed Processing Interface Definition Language
Архитектура открытого распределенного управления			ODMA	ISO/IEC 13244:1998, Information technology – Open Distributed Management Architecture
Эталонная модель окружения открытых систем				OSE RM	ISO/IEC 7498:1996, Information processing systems – Open Systems Interconnection – Basic Reference Model ITU-T Rec. X.200 (1994)
Эталонная модель управления данными				DM RM	DIS 9075:1992, Information technology – Reference Model for Data Management
Эталонная модель машинной графики				CG RM	ISO/IEC 11072:1992, Information Technology – Computer Graphics – Computer Graphics Reference Model
Эталонная модель открытой архитектуры документов и обмена форматами				ODA RM	ISO/IEC 8613/1:1994, Information technology – Open Document Architecture (ODA) and Interchange Format – Introduction and general principles. [ITU-T Rec. T.411(1993)]
Эталонная модель управления качеством и обеспечения качества				ISO 9000	ISO 9000-3 Quality management and quality assurance standards – Part 3: Guidelines for the application of ISO 9001 to the development, supply, installation and maintenance of computer software
Эталонная модель обеспечения качества при проектировании, разработке, производстве, установке и обслуживании.		ISO 9001 Quality systems – Model for quality assurance in design, development, production, installation and servicing
Эталонная модель обеспечения качества при производстве, установке и обслуживании.		ISO 9002 Quality systems – Model for quality assurance in production, installation and servicing
Эталонная модель обеспечения качества при финальных проверках и тестировании		ISO 9003 Quality systems – Model for quality assurance in final inspection and test
Эталонная модель управления качеством		ISO 9004-1 Quality management and quality system elements – Part 1: Guidelines
Эталонная модель жизненного цикла программного обеспечения				ISO/IEC 12207 Information technology – Software life cycle processes
Методы тестирования конформности				ISO/IEC DIS 13210, Information Technology – Test methods for measuring conformance to POSIX
ISO/IEC 9646-1: 1994/ITU-T X.290, ISO/IEC DIS 13210
Эргономика программных продуктов				ISO/IEC 9241. Ergonomic Standards for Computer Products
Управление безопасностью				ISO/IEC 7498, Information processing systems – Open Systems Interconnection – Basic Reference Model. Part 2: Security Architecture [ITU-T Rec. X.800 (1991)] ISO/IEC DTR 10181-1, Information processing systems – Open Systems Interconnection – Security frameworks in open systems: Security frameworks overview ISO/IEC DTR 13335-1: 1996 – Information Technology Guidelines for the Management of IT Security (GMITS)

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

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

Среди прочего, модель RM-ODP определяет пять точек зрения на систему:

· организационная точка зрения описывает постановку цели, области применения, способы и правила применения;

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

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

· инженерная точка зрения представляет распределение отдельных элементов системы по физическим ресурсам, а также их связи;

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

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

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

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

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

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

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

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

· Нотаризации (наделения правомочностью агентов).

· Журналирования (архивирования и неизменяемости).

· Транзакционности (определенности статусов).

· Внешнего доступа к внутренним статусам (наличие стандартного интерфейса).

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

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

Для определения уровней взаимодействия и отслеживания динамики развития информационных систем рекомендуется использовать совместимую с методикой Европейского союза классификацию фаз развития электронного взаимодействия:

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

2. Одностороннее действие: получение форм. Система может получить от пользователя запрос для последующей обработки.

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

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

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

В отношении ориентированных на граждан веб-систем (информационных порталов ведомств и т. п.) рекомендуется дополнительно использовать классификацию уровней взаимодействия, предложенную в методике ООН “United Nations e-Gov web measure survey” (см. таблицу).

Таблица 4.4.

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

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

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

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

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

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

4.2.2 Метаданные

Поскольку понятие метаданные (“данные о данных”) является весьма широким и допускает различные трактовки, для целей АПО принимается суженное толкование термина:

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

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

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

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

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

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

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

· технологические данные – сведения о языке, форматах и кодировках, а также сведения о местонахождении оригинального экземпляра описываемого документа;

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

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

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

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

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

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

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

При проектировании компонентных архитектур систем для нужд электронного государства рекомендуется использовать четырехслойную модель:

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

- доступ пользователей через веб-браузер;

- доступ внешних систем к функциям и информационным объектам через стандартизованные интерфейсы, в первую очередь – через веб-сервисы.

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

· Средний слой (слой предметной области) описывает ядро специфичных для процессов электронного государства компонентов. В среднем слое инкапсулируется специфичная логика данной информационной системы, и обрабатываются данные, получаемые из слоя источника. Средний слой должны стать основным источником компонентов для повторного использования в системах электронного государства. В связи с этим архитектура систем со средним слоем является особым случаем, когда АПО отходит от установления «чистых» стандартов взаимодействия и углубляется в вопросы внутренней реализации программ, определяя в качестве рекомендованной конкретную технологическую платформу Java 2 Enterprize Edition.

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

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

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

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

· Физическая защита системы.

· Максимально возможно высокая доступность и готовность систем.

· Повышение надёжности (устойчивости и доступности) систем и системных компонентов.

· Повышение информационной защищенности с учетом классификации потребностей в защите.

· Разделение систем по зонам безопасности.

· Масштабируемость систем и инфраструктуры.

· Простое и эффективное обслуживание персоналом.

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

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

1. Защищённое от радиопомех безопасное помещение.

2. Контроль доступа с персональной аутентификацией.

3. Система пожаротушения с некоррозийными и нетоксичными агентами.

4. Резервированная (дублирующая) система электропитания.

5. Системы кондиционирования и вентиляции.

6. Резервный удалённый центр хранения данных.

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

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

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

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