РЕФЕРАТ
Объем отчета:
Страниц - 49. Таблиц – 1. Иллюстраций – 6.
Ключевые слова:
АРХИТЕКТУРА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, ЭЛЕКТРОННОЕ ГОСУДАРСТВО, ЭЛЕКТРОННОЕ ПРАВИТЕЛЬСТВО, СТАНДАРТИЗАЦИЯ, ЖИЗНЕННЫЙ ЦИКЛ СТАНДАРТА, МЕЖДУНАРОДНЫЙ ОПЫТ, МЕЖСИСТЕМНОЕ ВЗАИМОДЕЙСТВИЕ, КАТАЛОГ СПЕЦИФИКАЦИЙ.
Текст реферата:
Объектом настоящего исследования являлись нормативно-технические документы, регулирующие вопросы стандартизации программного обеспечения в Австралии, Великобритании, Германии, Гонконге, Дании, Египте, Новой Зеландии и США
Целью исследования являлось выявление положительного зарубежного опыта, который мог бы стать ориентиром при выработке собственной политики в области построения архитектуры программного обеспечения для нужд электронного государства в России.
В ходе анализа были выявлены следующие важнейшие общие черты государственных политик в области стандартизации АПО, положенные в основу дальнейшей разработки нормативно-технической документации:
· обязательный характер как минимум части положений АПО при разработке информационных систем для нужд государства;
· наличие сводного каталога базовых спецификаций, использующего систему статусов для определения условий использования и жизненного цикла стандартов;
· приоритет международных стандартов над национальными, активное использование международного опыта, глобализация решений;
· ориентация на открытые системы и стандарты, вплоть до декларирования полного отказа от проприетарных решений в достаточно близкой перспективе;
· публичный характер документов в области АПО, в большом числе случаев – публичные процедуры их подготовки;
· использование XML в качестве метаязыка для моделирования информационных структур и обмена данными;
· ориентация на взаимодействие и использование интернет-технологий, в т.ч. определение веб-браузера в качестве основного клиента для государственных информационных систем при взаимодействии с гражданами и веб-сервисов при межсистемном взаимодействии;
· разработка собственных расширений существующих стандартов в области метаданных для специфических нужд электронного государства;
· заметное внимание, уделяемое проблемам обеспечения совместимости с унаследованными системами, выбывающим стандартам, и процедурам миграции.
Содержание
Введение 3
Основная часть 3
1 Германия. SAGA 3
1.1 Область применения, статус и цели 3
1.2 Структура документации 3
1.3 Организационные принципы 3
1.4 Технологические подходы 3
1.5 Порядок отбора спецификаций 3
1.6 Структура каталога спецификаций 3
1.7 Особенности архитектуры 3
2 Великобритания. Концепция взаимодействия e-GIF 3
2.1 Область применения, статус, цели 3
2.2 Структура документации 3
2.3 Организационные подходы 3
2.4 Технологические подходы 3
2.5 Порядок отбора спецификаций 3
2.6 Структура каталога спецификаций 3
2.7 Особенности концепции 3
3 США. Архитектура федерального предприятия 3
3.1 Статус и структура документов 3
3.2 Технологические подходы 3
4 Гонконг. Interoperability Framework 3
4.1 Область применения, статус и цели 3
4.2 Структура документа 3
4.3 Организационные принципы концепции 3
4.4 Технологические принципы концепции 3
4.5 Структура и состав каталога спецификаций 3
4.6 Особенности концепции 3
5 Новая Зеландия. NZ e-GIF 3
5.1 Статус, состав, цели документов 3
5.2 Организационные подходы 3
5.3 Технологические подходы 3
6 Австралия. AGTIF 3
6.1 Статус документа 3
6.2 Требования к стандартам 3
6.3 Структура и состав каталога стандартов 3
6.4 Особенности концепции 3
7 Дания. The Interoperability Framework 3
7.1 Статус и цели. Организационные подходы 3
7.2 Порядок отбора спецификаций 3
7.3 Структура каталога спецификаций 3
8 Египет 3
8.1 Статус, область применения, цели документа 3
8.2 Технологические подходы 3
9 Европейский союз. EIF. Краткий обзор 3
10 ЗАКЛЮЧЕНИЕ 3
Задачи и статусы документов 3
Принципы стандартизации и методика описания систем 3
Технологические принципы 3
Введение
В ходе настоящего исследования были рассмотрены основные нормативно-технические документы, определяющие политику ряда развитых и развивающихся государств в области стандартизации архитектуры программного обеспечения и информационных систем для нужд электронного государства.
Целью исследование являлось выявление общих тенденций и подходов к выбору и систематизации технических стандартов, используемых для организации межпрограммного взаимодействия в рамках электронного государства а также упорядочения процессов проектирования и разработки государственных систем.
Предпосылками для появления нормативно-технических документов такого рода является несогласованность технических и технологических политик различных государственных ведомств, порождающая:
сложность организации взаимодействия между многочисленными унаследованными и вновь внедряемыми государственными информационными системами, обилие несовместимых интерфейсов, форматов и протоколов, необходимость поддержки которых приводит к неоправданным затратам и плохой управляемости интегрированных систем;
неоправданные затраты, связанные с повторной разработкой практически однотипных компонентов, реализующих схожие административные процессы в различных ведомствах-заказчиках;
проблемы при организации доступа граждан к услугам электронного государства, связанные с использованием недоступных, несовместимых, закрытых и/или дорогостоящих технологий для клиентских приложений;
трудности, испытываемые «некомпьютерными» ведомствами при выборе технологий и обосновании технических требований к заказываемым информационным системам, навязывание поставщиками неоптимальных или несовместимых решений;
проблемы с управлением правами на программное обеспечение, использование большого количества закрытых проприетарных (частных) решений, порождающее сложности при повторном использовании, тиражировании, масштабировании и развитии приобретенных государством систем.
В качестве основного объекта анализа были выбраны три мировых лидера в области стандартизации АПО, чьи решения в этой области имеют наибольшую историю и во многом служат образцом для прочих стран, а именно Великобритания, Германия и Соединенные Штаты Америки. Для этих стран был проведен углубленный анализ и составлен сравнительный перечень стандартизованных спецификаций, установленных в качестве обязательных или рекомендованных для использования в государственных информационных системах (приводится в Пояснительной записке к архитектуре программного обеспечения).
Кроме того, на подготовительном этапе исследования был проделан обзор опубликованных документов других стран и выбран ряд государств, имеющих, по мнению исполнителей, наиболее ясную, интересную и хорошо формализованную политику в области АПО, а именно Австралию, Новую Зеландию и Гонконг.
В качестве примера решения подобных задач развивающейся страной с относительно низким уровнем проникновения информационно-коммуникационных технологий в сферу государственной деятельности был выбран Египет, одним из первых среди таких стран опубликовавший официальный документ в области интеграции информационных систем (концепцию межпрограммного взаимодействия).
Дополнительно были рассмотрены и описаны меры, предпринимаемые в области стандартизации межгосударственного информационного обмена в рамках Евросоюза - в той части, в которой общеевропейский опыт применим на государственном уровне.
При анализе документов использовался следующий план:
1. Определялся состав документов, регулирующих стандарты в области стандартов, выяснялся их юридический статус и степень обязательности применения в госструктурах соответствующей страны
2. Изучалась структура документов, выявлялись важнейшие части, разделы, самостоятельные приложения (такие, как каталоги спецификаций и т.п.);
3. Систематизировались продекларированные принципы разработки, механизмы поддержания в актуальном (соответствующем современному технологическому уровню) состоянии и средства обеспечения исполнения рассматриваемых документов;
4. Выделялись важнейшие технологические подходы, зафиксированные в нормативно-технической документации;
5. Описывались принципы отбора и классификации стандартов;
6. Выявлялись характерные особенности и различия документов, обусловленные местной спецификой.
Выявленные общие тенденции, которые могут быть учтены и использованы при построении отечественной системы регулирования в области АПО, перечислены и проанализированы в заключительной части отчета.
Основная часть
Германия. SAGA
Структура документации
При описании архитектуры приложений электронного правительства авторы SAGA используют Reference Model for Open Distributed Processing (RM-ODP, эталонная модель для открытой распределенной разработки, ISO 1996). Данная модель не является обязательной, но настоятельно рекомендуется для использования. Приложения электронного государства в SAGA рассматривается со следующих точек зрения:
· организационной (enterprise), описывающий общие подходы к моделированию процессов и построению информационных систем;
· информационной (information), описывающей свойства и семантику обрабатываемых данных;
· компонентной (computational), рассматривающей приложение как совокупность функциональных модулей и интерфейсов для их взаимодействия;
· инженерной (engineering), описывающей инфраструктуру, в т.ч. техническую и телекоммуникационную, необходимую для работы распределенных программных систем;
· технологической (technology), рассматривающей приложение как совокупность используемых в нем технологий.
Собственно предметом стандартизации являются технологические требования к приложениям, Концепции первых четырех представлений накладывают условия на технологические стандарты.
SAGA разработана, как новый ключевой документ в составе сводного издания документов KBSt, включающего более ранние концепции («V-модель», «Руководство по миграции», «DOMEA» и др.). Эти документы частично заменяются SAGA, а не охваченные в SAGA вопросы, освещенные в них, должны быть заново согласованы с учетом новой модели АПО, предлагаемой в SAGA. В то же время принято решение при дальнейшем написании SAGA избежать дальнейшего внесения разногласий между актуальными документами.
Организационные принципы
Подход SAGA основывается на повсеместном использовании стандартов в процессе реализации технических инициатив проекта электронного правительства Германии, которые сосредоточиваются на четырех направлениях (задачах):
· Выявлении технических нормативов, эталонов, стандартов и архитектур.
· Моделировании процессов.
· Моделировании данных.
· Создании базовых компонентов.
SAGA определяет строгую процедуру установления соответствия систем ее требованиям, включающую, в частности, декларирование соответствия разработчиками систем. Приложение для электронного правительства, удовлетворяющее требованиям SAGA, должно:
· применять стандартизированные модели процессов;
· использовать стандартизированные модели данных;
· обеспечивать совместимость с описанными в SAGA техническими стандартами и архитектурами;
· использовать существующие (ранее разработанные) базовые компоненты.
Для несоответствующих (неконформных) систем устанавливается целый ряд ограничений в использовании:
· ограничено использование базисных компонентов;
· консультационные услуги центров компетенции ограничиваются;
· интерфейсы таких систем не обслуживаются (не поддерживаются);
· субсидии, в особенности средства для инициативы BundOnline 2005, становятся невозможными;
· интеграция системы в портал www.bund.de становится невозможной.
Технологические подходы
Приложения для электронного правительства, согласно SAGA, разрабатываются в соответствии со следующими основополагающими принципами:
· приложения для электронного правительства используют в качестве фронт-энда браузер, переносимые сервисы отображаются только через браузер за исключением отдельных случаев, где это не представляется разумным;
· разработчики отказываются от использования активных компонентов, чтобы не принуждать пользователя к снижению порога безопасности в браузере, что может повлечь за собой повреждение данных пользователей из-за небезопасных веб-страниц, либо используют как минимум только подписанные и безопасные приложения в соответствии с определенными в SAGA процедурами и спецификациями;
· приложения для электронного правительства не записывают на компьютер пользователей никаких программных компонентов или данных, влекущих к потере пользователем контроля над своим компьютером.
SAGA декларирует однозначную ориентацию на открытые системы и, в частности, прямо оговаривает на необходимость отказа от использования закрытых решений Microsoft, что является довольно необычным шагом. В качестве альтернативы предусматривается использование платформ J2SP и J2EE.
В отличие от большинства других проектов в области АПО, SAGA определяет требования к приложениям не только на уровне взаимодействия, но и на уровне компонентной структуры. В качестве основной компонентной архитектуры предложена многослойная модель со средним слоем, показанная на Рис. 1.1:
Рис. 1 . 1 .
|
· Клиентский уровень модели представляет различные каналы доступа, различия которых обусловлены разными пользователями, терминалами, способами передачи и целями применения. В SAGA предусматриваться как минимум три канала доступа:
§ доступ пользователей через веб-браузер;
§ доступ пользователь через мобильные каналы (WAP, PDA);
§ доступ внешних систем через стандартизованные интерфейсы, в первую очередь – через веб-сервисы.
· Презентационный уровень описывает компоненты, выполняющие взаимодействие с пользователем и преобразование (трансформацию) информации к форме, пригодной для соответствующего клиента. Компонент презентации должен охватывать все стандарты коммуникации с рассмотренными на клиентском уровне терминалами.
· Средний слой (слой предметной области) описывает ядро специфичных для процессов электронного государства компонентов. В среднем слое инкапсулируется специфичная логика данной информационной системы и обрабатываются данные, получаемые из постоянного слоя. Средний слой определяется, как основной источником компонентов для повторного использования.
· Постоянный слой описывает хранение данных. Как правило, реализуется при помощи готовых СУБД. Кроме того, данный уровень является обобщающим понятием для средств операционной системы, специфичных информационных хранилищ, а также унаследованных систем, не соответствующих требованиям SAGA.
Интересным с российской точки зрения является учет в документе федеративной структуры государственных органов Германии. Организационная точка зрения SAGA устанавливает требования к налаживанию всех основных типов взаимодействия (G2С, G2B, G2G) в рамках электронного государства, при этом большое внимание уделяется взаимодействию с местными органами самоуправления.
Рекомендуемая SAGA модель взаимодействия показана на Рис. 1.2:
Рис. 1 . 2 .
|
Порядок отбора спецификаций
В SAGA определена достаточно сложная модель мониторинга и принятия стандартов, включающая основной каталог стандартов, в котором стандарты могут иметь следующие статусы:
· Обязательные. Стандарты являются обязательными, когда они одобрены м предоставляют предпочитаемое решение задачи. Эти стандарты рассматриваются и применяются в первую очередь. Конкурирующие стандарты могут быть одновременно обязательными, если основные задачи приложений явно различаются между собой. Если одновременно существуют обязательные и рекомендованные, либо находящиеся под наблюдением стандарты, то последние из них должны применяться лишь в обоснованных исключительных случаях. Обязательная классификация не обозначает, что стандарт применяется в каждом приложении для электронного правительства. Обязательный стандарт должен использоваться только в том случае, когда технология или функциональность, связанная со стандартом, является обязательной или желательной в контексте требований к определённому приложению.
· Рекомендованные. Рекомендация стандартов возможна в том случае, когда эти стандарты прошли проверку на надёжность, но либо не являются необходимыми (например, не обеспечивают оптимальное решение задачи), либо ещё не прошли рассмотрение в качестве обязательных стандартов. Если помимо рекомендуемых стандартов не существует конкурирующих обязательных стандартов, обоснованное отклонение от рекомендуемых стандартов возможно только в порядке исключения. Конкурирующие стандарты могут быть одновременно рекомендуемыми, если различия в их применении чётко разграничены. В таких случаях для каждого отдельного случая выбирается наиболее подходящий стандарт. В случае одновременного существования рекомендуемых и наблюдаемых стандартов последние из них могут обоснованно применяться лишь в порядке исключения.
· Под наблюдением. Стандарты находятся под наблюдением в том случае, когда они следуют в желаемом направлении развития, но при этом не являются достаточно зрелыми, либо ещё не закрепились на рынке.
Помимо классифицированных в каталоге, совместно в SAGA ведутся ещё три справочных списка стандартов, которые обзорно представляют:
· Новые, ещё не прошедшие оценку стандарты (Белый список).
· Устаревшие стандарты, от которых отказались (Чёрный список).
· Готовящиеся к введению в эксплуатацию стандарты (Серый список).
Процессы изменения статусов стандартов показаны на Рис. 1.3:
Рис. 1 . 3 .
|
1. Новый стандарт предлагается для включения в классификатор командой разработчиков, экспертами, участниками форума. Предложенный стандарт включается в “белый” список на сайте. Из позиции 1 возможен переход в позицию 3 за один шаг.
2. Стандарты, не прошедшие оценку и не включенные в классификатор, переносятся в “черный” список отвергнутых стандартов.
3. Стандарт с позитивными результатами тестирования добавляется в следующую версию классификатора.
4. Стандарт, вошедший со статусом «рассматриваемый» получает статус «рекомендуемый» в следующей версии классификатора.
5. Вошедший стандарт со статусом «рекомендуемый» получает статус «одобренный».
6. Стандарт, вошедший со статусом «одобренный», получает статус «рекомендуемый». Переход из 6 в 7 может быть выполнен за один шаг.
7. Стандарт, вошедший со статусом «рекомендуемый», не включается в следующую версию классификатора, а переходит в серый список.
8. Устаревшие стандарты из серого списка, которые более не используются и не поддерживаются, перемещаются в «черный» список.
9. Стандарты со статусом «рассматриваемый», которые не прошли проверку на соответствие принципам SAGA, переносятся в «черный» список.
Особенности архитектуры
В отдельный раздел архитектурной модели, не предусмотренный в пятизвенной схеме ODP, выделены вопросы безопасности информационных систем. SAGA демонстрирует хорошо систематизированный и в то же время понятный подход к описанию требований по безопасности, показанный на Рис. 1.4:
Рис. 1 . 4 .
|
Структура документации
Давняя история электронных государственных ИС Великобритании и стабильность структуры административного управления объясняют развитую структуру документов, регламентирующих процедуры и технологии взаимодействия.
В архитектуре e-GIF выделяется два уровня:
1. концептуальная основа (Framework), в которой определены высокоуровневые принципы и политики в отношении создания среды взаимодействия;
2. регистр e-GIF (Registry), содержащий следующие документы и каталоги:
§ Государственный стандарт на метаданные (e-GMS), приложением к которому является «список правительственных категорий метаданных» – Government Category List (GCL).
§ Каталог государственных стандартов данных – Government Data Standards Catalogue (GDSC), содержащий перечень принятых схем и форматов, разработанных специально для нужд государственного электронного взаимодействия.
§ Репозиторий XML-схем (XML schemas).
§ Каталог технических стандартов – Technical Standards Catalogue (TSC).
Организационные подходы
В руководстве e-GIF выделяется пять целевых групп служб, которые должны функционировать на уровне федеральной администрации и которые можно назвать миссией системы электронного правительства, а именно:
· Правительство и граждане (UK Government and citizens).
· Правительство и посредники (UK Government and intermediaries).
· Правительство и бизнес (UK Government and business).
· Правительство и правительство (UK Government organizations).
· Правительство и другие правительства (UK Government and other governments (UK/EC, UK/US, etc.).
В документе подробно рассматриваются стороны, заинтересованные в использовании принятой системы стандартов. Такими заинтересованными сторонами являются:
· Стратеги компаний, для которых важно, чтобы их стратегии соответствовали стратегии и технической политике государства. Соответствие стандартам это составная часть тендерных требований, без соответствия которым финансирование проектов не осуществляется.
· Руководители компаний, руководители проектов, ответственные за релевантность своей продукции и услуг, поставляемых по государственным контрактам.
· Финансисты, которые должны быть уверены, что инвестиции вкладываются в проект, соответствующий тендерной документации.
· Государственные служащие, заключающие государственные контракты на закупку продукции, которые должны быть уверены в соответствии продукции и услуг процедурам контрактации.
· Поставщики, разработчики программного обеспечения и ИКТ, которые должны знать технические требования, которым должна удовлетворять их продукция или услуги.
· Аудиторы проектов, сотрудники казначейства (аналога российской Счетной Палаты), парламентских комитетов, которые должны иметь инструментарий для проведения аудита государственных информационных систем и принятии решений об эффективности использования бюджетных средств.
Документ e-GIF предусматривает процедуру публичного обсуждения при публикации проекта очередной версии. Особое внимание уделяется вовлечению общественности, разработчиков стандартов, а также организаций, занимающихся внедрением стандартов в процесс стандартизации. Для этого в рамках поддержки развития e-GIF развиваются интернет-сервисы:
· для контактов с разработчиками стандартов;
· для поощрения любых заинтересованных лиц участвовать в обсуждении стандартов;2;
· для поддержки стандартов;
· для рассылки приглашений участия в разработке и одобрении стандарта (Request for Proposals, Request for Comments).
Большое внимание в Великобритании уделяется поддержке стандартов, включенных в eGIF TSC. Система поддержки:
· отражает практику применения стандартов;
· содержит справочные материалы (руководства, схемы, опыт использования, вопросы-ответы, базы знаний);
· включает различные приложения (утилиты, инструментальные средства, листы проверки и т. п.);
· включает тренинги для различных категорий пользователей стандартов;
· содержит регламенты администрирования.
Одобрение стандартов общественностью рассматривается, в некоторой степени, как формальное утверждение стандарта. Система поддержки направлена на сбор мнений общественности и специалистов о предлагаемом стандарте. Если стандарт не вызывает значительных споров и возражений, более того, поддерживается общественностью, то он считается формально утвержденным и включается в каталог стандартов. Описанный подход реализуется через приглашения комментировать стандарты, технические документы, схемы XML.
По некоторым стандартам, особенно по перспективным, сразу невозможно принять решение о включении в каталог. Более того, иногда нет даже однозначного проекта такого стандарта. В этом случае системой стандартизации рассылаются приглашения о предложениях, на инновационные решения. Любые общественные группы могут принять участие или разработать самостоятельно проект подобного стандарта.
Технологические подходы
Технические решения, представленные в e-GIF, реализуются в соответствии со следующими ключевыми принципами:
· соответствие (alignment) требованиям Internet: заимствование и принятие технических особенностей, характерных для всех государственных информационных систем, существующих во всемирной сети Интернет;
· принятие XML как основного стандарта интеграции и работы с данными в государственных информационных системах;
· использование браузера как ключевого приложения: вся информация, размещенная в государственных информационных системах должна быть доступна через браузеры; другие приложения разрешены при условии их соответствия приложениям, основанным на технологии браузеров;
· использование метаданных для описания государственных ресурсов, развитие и принятие стандарта на метаданные электронного правительства e-GMS, в основе которого лежит модель Дублинского ядра (ISO 15836);
· развитие и поддержка правительственного списка категорий данных (Government Category List, GCL).
Порядок отбора спецификаций
Основными критериями отбора стандартов e-GIF являются:
· интероперабельность;
· распространенность на рынке;
· масштабируемость;
· открытость;
· интернациональность (международные стандарты имеют приоритет перед стандартами ЕС, а стандарты ЕС – перед национальными стандартами при прочих равных условиях).
К программному обеспечению, которым комплектуются государственные информационные системы, предъявляются отдельные требования на соответствие стандартам Open Source Software (OSS).
В состав e-GIF входит Каталог технических спецификаций (TSC), который устанавливает перечень стандартов и технологий, которые должны использоваться или рекомендованы для решения указанных задач. Каталог предусматривает следующие статусы спецификаций:
· Принятые (A) – обязательные для применения стандарты.
· Рекомендованные (R) – желательные для применения стандарты.
· На рассмотрении (U) – стандарты, которые в настоящее время проходят процедуру принятия в качестве обязательных или рекомендованных.
· Для будущего использования (F) – стандарты, которые в настоящее время не могут использоваться в системах электронного государства из-за недостаточной зрелости, но должны быть приняты к рассмотрению в будущем.
Заинтересованные стороны принимают решения, руководствуясь только стандартами со статусом «одобренный». Стандарты с другими статусами публикуются для сведения.
Особенности концепции
Особенностью e-GIF можно считать то, что в каталог стандартов eGIF TSC включено достаточно большое количество оригинальных разработок, для которых не существует адекватных международных аналогов. В основном это относится к форматам представления административных данных и метаданных (спецификации, разработанные в рамках проекта GovTalk).
В некоторой степени недостатком e-GIF можно считать включение в высокоуровневый концептуальный документ постоянно изменяющихся технических деталей, чем объясняется частота его пересмотра.
3 США. Архитектура федерального предприятия
Технологические подходы
В той или иной степени вопросы, относящиеся к архитектуре ПО, рассматриваются на различных уровнях FEA, однако наиболее полное описание технологических принципов дано в технической эталонной модели (TRM), структура которой показана на рисунке ниже.
Техническая эталонная модель включает четыре основных области сервисов:
· Доставка сервисов и предоставление к ним доступа (Service Access and Delivery). – относится к совокупности стандартов и спецификаций для поддержки внешнего доступа, обмена и доставки сервисных компонентов или возможностей. Эта область также включает законодательные и регулирующие требования, управляющие доступом и использованием специальных Сервисных компонентов.
· Платформа и инфраструктура сервисов (Service Platform & Infrastructure) – относится к средствам предоставления и поддержки платформ, возможностей инфраструктуры и аппаратного оборудования для поддержания проектирования, обслуживания и обеспечения доступности сервисных компонентов или функциональных средств.
· Среда для встраивания компонентов (Component Framework) – относится к базовым принципам, технологиям, стандартам и спецификациям, на основе которых сервисные компоненты строятся, обмениваются и разворачиваются в пределах компонентной, распределенной или сервисно-ориентированной архитектуры.
· Сервисные интерфейсы и интеграция сервисов (Service Interface and Integration) – относится к совокупности технологий, методологий, стандартов и спецификаций, которые определяют способы создания интерфейсов (как внутренних, так и внешних) с Сервисными компонентами. Эта область также определяет методы, на основе которых компоненты будут взаимодействовать и интегрироваться с внутренними активами офиса и с наследуемыми активами.
Техническая модель предусматривает многоуровневую архитектуру приложений, определяя стандарты для каждого уровня:
· Уровень обеспечения безопасности. Этот уровень предоставляет всеохватывающую совокупность средств и услуг, которые включают регистрацию компонентов, установление подлинности пользователя, валидацию, шифрование и другие средства и услуги.
· Уровень представления. Уровень представления (или интерфейс пользователя) обеспечивает пользователей удобными в работе экранами для выполнения их задач или бизнес-функций; сюда входят формы, отчеты и т. д.
· Уровень бизнес-логики. Уровень бизнес-логики содержит вычисления, алгоритмы, компоненты и функции, которые будут выполнять все специальные задачи и/или запросы (осуществлять поиск, формировать запросы в базу данных, сохранять данные и т. д.).
· Уровень управления транзакциями. Данный уровень выступает как «координатор», который призван гарантировать, что все действия будут выполнены должным образом и окажутся результативными.
· Уровень хранения информации. Уровень хранения информации обеспечивает все действия по накоплению, хранению и управлению действующей информацией (сюда входят базы данных, хранилища знаний, наследуемые системы).
Рис. 3 . 5 .
|
В качестве приоритетов развития архитектуры ПО определены, в частности:
· повсеместное использование языка XML для интеграции данных;
· расширение использования веб-сервисов при взаимодействии.
Офис FEA-PMO провел также анализ рекомендуемых платформ, поддерживающих компонентно-базированную архитектуру, в основу которого были положены перечисленные в таблице критерии:
Таблица 3 . 1 .
| Критерий | J2EE/Web Services | NET/Web Services | J2EE/FTP | NET/FTP |
| Переносимость (portability) между разными платформами, независимость от операционной системы | +++ | + | +++ | + |
| Уровень зрелости технологии (не является ли она устаревшей) | ++ | + | +++ | ++ |
| Свободная интеграция гетерогенных (неоднородных) систем | +++ | +++ | ++ | + |
| Независимость от инфраструктур | +++ | +++ | ++ | ++ |
| Базирование на стандартах | +++ | ++ | +++ | ++ |
| Расширяемость | +++ | + | +++ | ++ |
| Легкость развития и интеграции | ++ | +++ | + | ++ |
| Прикладная интероперабельность и поддержка языков программирования | +++ | +++ | + | + |
| Финальный анализ | 22/24 | 17/24 | 18/24 | 13/24 |
Примечание: “+” – низкий уровень возможностей; “++” – средний уровень; “+++” – высокий уровень.
Значительное внимание в FEA уделяется вопросам поддержки унаследованных систем и процедурам миграции.
Необычным в мировом масштабе шагом стала передача не только формирования профилей стандартов или аналогичных документов, но и собственно стандартизации в области информационных технологий из ведома национального органа стандартизации (NIST) в ведение специального федерального бюро. Успех и обоснованность этой меры сложно оценить, так как OMB не выпущено пока ни одного стандарта.
Структура документа
Основные содержательные разделы документа (то есть за вычетом вводных, обзорных и справочных) посвящены следующим темам:
· Определение области применения и целей документа.
· Процедура управления концепцией взаимодействия, включая определение границ компетенции правительственных ведомств, условия участия, порядок внесения изменений.
· Определение условий и политики соответствия требованиям концепции, а также процедуры для исключений.
· Принципы выбора областей регулирования и технических спецификаций.
· Список (каталог), технических спецификаций, установленных для определенных областей взаимодействия.
· Описание архитектуры правительственной сети.
Документ покрывает все основные вопросы взаимодействия, определяя спецификации, процедуры и правила для правительственной информационной сети. Частные вопросы взаимодействия, рекомендации, справочные сведения, руководства по применению и др. материалы, не вошедшие в основной документ концепции, публикуются на официальном интернет-ресурсе правительства «IT in Government Information Station» (ITG InfoStation), который рассматривается, как часть среды взаимодействия. Там же публикуются принятые правительством схемы данных для взаимодействия с использованием XML.
Особенности концепции
Основной особенностью предложенного в Гонконге подхода является четкая ориентация на поддержку решений рынком, так, концепция прямо устанавливает, что государство не должно (в рамках данного документа) пытаться регулировать применение стандартов de-facto, сложившихся в определенных информационных отраслях. В этом факте проявляются успехи, достигнутые правительством Гонконга на пути к преобразованию правительства к сервисной структуре, практически уравненной в правах с бизнес-субъектами.
Следует отметить, что подобные результаты во многом объясняются малыми размерами данного административного образования и его специфическим статусом, в связи с чем этот опыт не может быть прямо рекомендован для такого государства, как Россия.
В то же время заслуживает безусловного внимания сам спектр рекомендованных концепцией технических решений, простая и удобная структура документа, внятность формулировок, а также четко обозначенные подходы к управлению жизненным циклом документа и процедурами подтверждения соответствия.
Новая Зеландия. NZ e-GIF
Организационные подходы
Разработка и развитие NZ e-GIF осуществляется в соответствии со стратегическим планом (Roadmap for the e-GIF). План предусматривает регулярное обновление версий NZ e-GIF с учетом предложений всех заинтересованных правительственных агентств, а в некоторых случаях – публичного сектора. Рассмотрение предложений осуществляется специальной рабочей группой.
Участие правительственных агентств в процессе регламентируется специальными соглашениями, в которых определяются:
· Роль и ответственность каждого агентства.
· Процессы, поручаемые агентству и требуемый уровень сервиса.
· Процедуры измерения уровня каждого сервиса и порядок решения проблем.
· Требования к качеству данных.
· Порядок взаимной компенсации затрат.
Технологические подходы
Для описания и классификации функций в правительственных информационных системах используется нестандартная многослойная функциональная модель, показанная на Рис. 5.6:
Рис. 5 . 6 .
|
Некоторые термины модели общеприняты, а некоторые имеют достаточно нестандартное толкование:
· Сеть –определяет базовые транспортные протоколы.
· Архитектура – определяет на уровне синтаксиса способы представления данных, которые должны использоваться при информационном взаимодействии. В качестве основной технологии представления данных, как и следовало ожидать, определен XML.
· Сервисы предметной области – определяют, как именно интерпретируется и используется потоки данных в тех или иных приложениях (например, как должны представляться имена или адреса в XML).
· Доступ и представление – слой описывает способы и каналы доступа пользователей и систем к данным и сервисам, в т.ч. требования к веб-интерфейсам.
· Безопасность – пронизывает все слои модели, реализуя политику государства в области защиты информации.
· Компоненты электронного правительства – описывает конкретные реализации и инфраструктурные компоненты, доступные правительственным агентствам и публичному сектору.
· Руководство и управление – внешние по отношению к модели e-GIF слои, описанные в предыдущем разделе. Спецификации в этих областях не установлены.
Таксономия каталога стандартизованных спецификаций NZ e-GIF соответствует описанной выше модели. Документ не устанавливает явных требований к спецификациям и стандартам, используемым в сфере электронного государства, хотя на практике в большинстве областей приняты открытые международные стандарты. Исключение составляют специфические схемы данных и метаданных, которые для нужд новозеландского государства разрабатываются различными правительственными агентствами самостоятельно.
Каталог предусматривает только два статуса принятых стандартов – обязательные и рекомендованные.
Австралия. AGTIF
Статус документа
Вопросами регулирования применения информационных технологий в Австралии заведует Государственный офис управления информацией (Australian Government Information Management Office – AGIMO). К области ведения AGIMO относится:
· разработка концепций технического взаимодействия в правительстве;
· разработка концепции аутентификации пользователей (в т.ч. с использованием интеллектуальных карт и т. п. технологии);
· разработка руководств по выбору и закупкам информационно-коммуникационных решений для правительственных агентств и государственных ведомств;
· разработка стратегического плана создания, развития и продвижения государственных сервисов.
Вопросы стандартизации технического взаимодействия государственных органов Австралии рассматриваются в официальном документе Australian Government Technical Interoperability Framework (AGTIF). В документе указываются следующие принципы технического взаимодействия:
· Взаимодействие между государственными органами должно быть основано на стандартах и возможностях ИКТ.
· Существующие национальные и международные стандарты должны быть адаптированы, стать доступными и приемлемыми.
· Все стандарты и руководства обязаны соответствовать принципам открытых стандартов.
Требования к стандартам
Стандарты, включаемые в каталог стандартов должны соответствовать:
· принципам взаимодействия;
· критериям открытого стандарта.
В документе следующим образом формулируются критерии открытого стандарта:
· отсутствие роялти;
· отсутствие дискриминации вендоров;
· возможность беспрепятственного расширения стандарта;
· возможность повторного использования;
· сокращение риска «тупиковых» технологий;
· как следствие, всего вышеперечисленного, минимальные издержки при осуществлении взаимодействия между государственными органами.
Такой подход определяет общедоступность и гибкость взаимодействия государственных органов.
Стандарты, включаемые в каталог, допускают различие правовых моделей. В том числе, это отражается на величине и необходимости оплачивать копию стандарта. Приняты следующие правовые модели:
· открытый – означает, что условия платежей определяет организация стандартизации;
· коммерческий – означает стандарт, требующий платежей;
· государственный – означает стандарт, находящийся в публичном доступе.
Каждому этапу жизненного цикла стандарта в процессе его использования присваивается определенный статус:
Развивающийся – стандарт, который несмотря на то, что не используется широко в настоящее время, перспективен в будущем.
Текущий – стандарт, который широко используется и хорошо поддерживается в настоящее время.
Исчезающий – стандарт, который еще используются, но все реже поддерживается и в целом снимается с эксплуатации.
Существует особый статус «сообщество интересов». Это означает, что данный стандарт может использоваться для совершенно различных групп интересов и в этих группах у него различные этапы жизненного цикла. Например, в одной группе он может получить статус «текущий», а в другой – «развивающийся». Решения о статусе «сообщество интересов» устанавливает само сообщество. Оно же принимает решение о приемлемости и правилах применения.
Особенности концепции
Наиболее интересной особенностью документа AGTIF является наличие в нем специального раздела, посвященного рассмотрению «образцов передового опыта» (case studies) – практических примеров использования концептуальных положений документа в конкретных приложениях австралийского электронного государства.
Порядок отбора спецификаций
Основой для выбора подходов к процессам стандартизации, критериев оценки стандартов служит оценка выгод, приносимых стандартом государству и гражданам. Стандарт должен сокращать социальные и экономические издержки общения граждан с государством (транзакционные издержки).
Для каждого стандарта в каталоге устанавливается статус. Определение статуса основано на следующих критериях оценки:
· Распространенность.
· Открытость.
· Зрелость.
· Приемлемость в национальном контексте.
· Полезность в контексте электронного государства.
В зависимости от оценки стандарту присваивается один из следующих статусов:
Рекомендуемый. Стандарт желателен для использования в системах eGov.
Одобренный. Стандарт обязательно должен поддерживаться в системах, где он функционально применим.
Развивающийся. Стандарт может быть полезен в будущем, но в текущее время никаких выгод не приносит.
Де факто. Стандарт широко используется в своей области применения.
Поддерживаемый. Стандарт, который устарел (исчерпал выгоды), но еще используется.
Миграция. Указывает, что осуществляется постепенный переход на другой стандарт, являющихся лучшим решением. Статус указывает на то, что по мере возможности необходимо отказываться от данного стандарта.
Статусы помогают принимать решения при инвестировании новых проектов в области ЭГ.
Статусы «рекомендуемый», «одобренный» и «де факто» представляют область, в которую можно осуществлять технические или экономические инвестиции. «Одобренные» стандарты используются для развития среды стандартов и развития взаимодействия. Стандарты со статусом «поддерживаемый» и «миграция» указывают на окончание жизненного цикла стандарта. В новых проектах от этих стандартов рекомендуется воздерживаться. Стандарты «развивающиеся» следует использовать в пилотных проектах для выявления выгод и рисков.
Египет
Технологические подходы
Стандарт устанавливает четырехслойную модель описания приложений электронного государства, включающую:
· Слой представления – соответствует слою клиента в более общепринятой терминологии, описывает различные каналы доступа к государственному контенту и сервисам.
· Слой веб-приложений – соответствует слою представления в более общепринятой терминологии. Устанавливает веб-технологии в качестве основного способа доступа к системам электронного государства. Рекомендует развитие веб-порталов.
· Слой бизнес-приложений (предметной логики) – соответствует общепринятому пониманию в архитектурах со средним слоем.
· Информационный слой – соответствует слою хранения в общепринятой терминологии.
Описан также отдельный административный мета-слой, описывающий принципы управления технологическими слоями, определяющий схемы данных и метаданных, принципы именования и присвоения идентификаторов, политики доступа к данным и сервисам и т. п.
Классификация стандартизованных спецификаций также осуществляется в рамках принятой четырехслойной модели, причем на информационном слое определены конкретные форматы специфических данных (документы, таблицы, графика, мультимедийные файлы и т. п.).
Стандарт проповедует следующие основные технологические подходы:
· использование XML в качестве метаязыка представления данных и XSL в качестве средства их трансформации для представления;
· использование UNICODE для представления текстов;
· использование веб-браузеров, как основного клиентского приложения с системах электронного государства;
· необходимость развития мобильного доступа посредством WAP и аналогичных технологий.
Особое внимание (очевидно, с учетом национальной специфики) уделено развитию государственных каналов интерактивного телевидения.
ЗАКЛЮЧЕНИЕ
Сравнительный анализ описанных документов позволил выявить общие черты, которые можно рассматривать, как универсальные решения, подкрепленные, среди прочего, многолетним опытом развитых стран в области стандартизации АПО.
С другой стороны, в документах выделяется ряд общих задач и проблем, которые при этом решаются по-разному в разных государствах и, соответственно, в этой области также можно предположить необходимость разработки оригинальных решений, учитывающих российскую специфику и особенности концепции электронного государства.
Окончательное обобщение результатов исследования приведено в Пояснительной записке к АПО, приложением к которой является настоящий отчет.
Задачи и статусы документов
Как правило, в большинстве проанализированных документов функциональной стандартизации упор делается на описание концепции межсистемного взаимодействия (interoperability framework, IF) государственных информационных систем друг с другом и с гражданами-пользователями. Основной задачей документов такого рода является определение коммуникационных протоколов разных уровней, форматов данных и межсистемных интерфейсов, а целью – обеспечение прозрачных информационных потоков между государственными ведомствами и свободный доступ граждан и негосударственных организаций к информационным ресурсам и сервисам электронного государства.
Более глубоко и широко архитектура ПО рассматривается в Германии и США, где в дополнение к задачам взаимодействия рассмотрена также компонентная структура приложений. Целью этого является обеспечение возможности более эффективного использования финансовых средств при разработке новых систем за счет повторного использования уже созданных ранее компонентов.
Американская концепция («Архитектура федерального предприятия», FEA) демонстрирует наиболее широкий подход к вопросам построения архитектуры электронного государства, описывая не только чисто технологические подходы, но и задачи проектирования государственных «бизнес-процессов». Это в определенной степени выводит FEA за пределы задач АПО, а достаточно жесткая привязка к специфике американской государственной системы затрудняет прямое использование полезного опыта. Напротив, документ SAGA демонстрирует удачное сочетание системности и прагматизма: с одной стороны, он описывает достаточно конкретные задачи стандартизации программного обеспечения, с другой стороны, используемые для этого методики достаточно универсальны и могут быть легко освобождены от национальной специфики.
Следует подчеркнуть обязательный характер всех рассмотренных документов. Их требования должны соблюдаться при разработке любых информационных систем для нужд государства в соответствующих странах. Большинство документов предусматривает специальные процедуры подтверждения соответствия систем установленным требованиям, а допустимые исключения строго оговорены.
Следует отметить также, что документы при этом не носят характера технического регламента – ни одна их концепций не предпринимает попыток регулирования технологий за пределами конкретной задачи - защиты интересов государства и граждан при разработке информационных систем. Большинство документов декларирует принцип невмешательства в архитектуру информационных систем негосударственного сектора в явной форме.
Разработка и корректировка документов в области АПО во всех случаях осуществляется специальным правительственным органом – межведомственным, или подчиненным специальному министерству, ответственному за информатизацию госструктур. Порядок принятия документов на межведомственном уровне, разумеется, сильно зависит от принятых в соответствующей стране административных правил. Так, например, в Новой Зеландии обязательность «концепции взаимодействия» определена на высшем правительственном уровне – решением кабинета министров. В Великобритании документ принимается на министерском уровне (Cabinet Office), что автоматически делает его обязательным и для других ведомств в силу компетенции соответствующего министерства.
Технологические принципы
Общими чертами всех рассмотренных документов в области АПО являются:
· принятие XML в качестве метаязыка для моделирования информационных структур и обмена данными;
· ориентация на использование Интернета и интернет-технологий;
· выбор веб-браузера в качестве основного клиента для государственных информационных систем при взаимодействии с гражданами;
· принятие технологии веб-сервисов в качестве основной при межсистемном взаимодействии.
Все документы уделяют внимание следующим сложным вопросам АПО, предлагая различные решения, учитывающие национальную специфику
· разработка собственных расширений существующих стандартов в области метаданных для специфических нужд электронного государства;
· обеспечение совместимости с унаследованными системами, поддержка выбывающих стандартам, выбор процедур миграции;
· поддержку национальных алфавитов и языков (в случаях, когда они отличаются от английского языка, ставшего стандартом де-факто при международном информационном взаимодействии).
РЕФЕРАТ
Объем отчета:
Страниц - 49. Таблиц – 1. Иллюстраций – 6.
Ключевые слова:
АРХИТЕКТУРА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, ЭЛЕКТРОННОЕ ГОСУДАРСТВО, ЭЛЕКТРОННОЕ ПРАВИТЕЛЬСТВО, СТАНДАРТИЗАЦИЯ, ЖИЗНЕННЫЙ ЦИКЛ СТАНДАРТА, МЕЖДУНАРОДНЫЙ ОПЫТ, МЕЖСИСТЕМНОЕ ВЗАИМОДЕЙСТВИЕ, КАТАЛОГ СПЕЦИФИКАЦИЙ.
Текст реферата:
Объектом настоящего исследования являлись нормативно-технические документы, регулирующие вопросы стандартизации программного обеспечения в Австралии, Великобритании, Германии, Гонконге, Дании, Египте, Новой Зеландии и США
Целью исследования являлось выявление положительного зарубежного опыта, который мог бы стать ориентиром при выработке собственной политики в области построения архитектуры программного обеспечения для нужд электронного государства в России.
В ходе анализа были выявлены следующие важнейшие общие черты государственных политик в области стандартизации АПО, положенные в основу дальнейшей разработки нормативно-технической документации:
· обязательный характер как минимум части положений АПО при разработке информационных систем для нужд государства;
· наличие сводного каталога базовых спецификаций, использующего систему статусов для определения условий использования и жизненного цикла стандартов;
· приоритет международных стандартов над национальными, активное использование международного опыта, глобализация решений;
· ориентация на открытые системы и стандарты, вплоть до декларирования полного отказа от проприетарных решений в достаточно близкой перспективе;
· публичный характер документов в области АПО, в большом числе случаев – публичные процедуры их подготовки;
· использование XML в качестве метаязыка для моделирования информационных структур и обмена данными;
· ориентация на взаимодействие и использование интернет-технологий, в т.ч. определение веб-браузера в качестве основного клиента для государственных информационных систем при взаимодействии с гражданами и веб-сервисов при межсистемном взаимодействии;
· разработка собственных расширений существующих стандартов в области метаданных для специфических нужд электронного государства;
· заметное внимание, уделяемое проблемам обеспечения совместимости с унаследованными системами, выбывающим стандартам, и процедурам миграции.
Содержание
Введение 3
Основная часть 3
1 Германия. SAGA 3
1.1 Область применения, статус и цели 3
1.2 Структура документации 3
1.3 Организационные принципы 3
1.4 Технологические подходы 3
1.5 Порядок отбора спецификаций 3
1.6 Структура каталога спецификаций 3
1.7 Особенности архитектуры 3
2 Великобритания. Концепция взаимодействия e-GIF 3
2.1 Область применения, статус, цели 3
2.2 Структура документации 3
2.3 Организационные подходы 3
2.4 Технологические подходы 3
2.5 Порядок отбора спецификаций 3
2.6 Структура каталога спецификаций 3
2.7 Особенности концепции 3
3 США. Архитектура федерального предприятия 3
3.1 Статус и структура документов 3
3.2 Технологические подходы 3
4 Гонконг. Interoperability Framework 3
4.1 Область применения, статус и цели 3
4.2 Структура документа 3
4.3 Организационные принципы концепции 3
4.4 Технологические принципы концепции 3
4.5 Структура и состав каталога спецификаций 3
4.6 Особенности концепции 3
5 Новая Зеландия. NZ e-GIF 3
5.1 Статус, состав, цели документов 3
5.2 Организационные подходы 3
5.3 Технологические подходы 3
6 Австралия. AGTIF 3
6.1 Статус документа 3
6.2 Требования к стандартам 3
6.3 Структура и состав каталога стандартов 3
6.4 Особенности концепции 3
7 Дания. The Interoperability Framework 3
7.1 Статус и цели. Организационные подходы 3
7.2 Порядок отбора спецификаций 3
7.3 Структура каталога спецификаций 3
8 Египет 3
8.1 Статус, область применения, цели документа 3
8.2 Технологические подходы 3
9 Европейский союз. EIF. Краткий обзор 3
10 ЗАКЛЮЧЕНИЕ 3
Задачи и статусы документов 3
Принципы стандартизации и методика описания систем 3
Технологические принципы 3
Введение
В ходе настоящего исследования были рассмотрены основные нормативно-технические документы, определяющие политику ряда развитых и развивающихся государств в области стандартизации архитектуры программного обеспечения и информационных систем для нужд электронного государства.
Целью исследование являлось выявление общих тенденций и подходов к выбору и систематизации технических стандартов, используемых для организации межпрограммного взаимодействия в рамках электронного государства а также упорядочения процессов проектирования и разработки государственных систем.
Предпосылками для появления нормативно-технических документов такого рода является несогласованность технических и технологических политик различных государственных ведомств, порождающая:
сложность организации взаимодействия между многочисленными унаследованными и вновь внедряемыми государственными информационными системами, обилие несовместимых интерфейсов, форматов и протоколов, необходимость поддержки которых приводит к неоправданным затратам и плохой управляемости интегрированных систем;
неоправданные затраты, связанные с повторной разработкой практически однотипных компонентов, реализующих схожие административные процессы в различных ведомствах-заказчиках;
проблемы при организации доступа граждан к услугам электронного государства, связанные с использованием недоступных, несовместимых, закрытых и/или дорогостоящих технологий для клиентских приложений;
трудности, испытываемые «некомпьютерными» ведомствами при выборе технологий и обосновании технических требований к заказываемым информационным системам, навязывание поставщиками неоптимальных или несовместимых решений;
проблемы с управлением правами на программное обеспечение, использование большого количества закрытых проприетарных (частных) решений, порождающее сложности при повторном использовании, тиражировании, масштабировании и развитии приобретенных государством систем.
В качестве основного объекта анализа были выбраны три мировых лидера в области стандартизации АПО, чьи решения в этой области имеют наибольшую историю и во многом служат образцом для прочих стран, а именно Великобритания, Германия и Соединенные Штаты Америки. Для этих стран был проведен углубленный анализ и составлен сравнительный перечень стандартизованных спецификаций, установленных в качестве обязательных или рекомендованных для использования в государственных информационных системах (приводится в Пояснительной записке к архитектуре программного обеспечения).
Кроме того, на подготовительном этапе исследования был проделан обзор опубликованных документов других стран и выбран ряд государств, имеющих, по мнению исполнителей, наиболее ясную, интересную и хорошо формализованную политику в области АПО, а именно Австралию, Новую Зеландию и Гонконг.
В качестве примера решения подобных задач развивающейся страной с относительно низким уровнем проникновения информационно-коммуникационных технологий в сферу государственной деятельности был выбран Египет, одним из первых среди таких стран опубликовавший официальный документ в области интеграции информационных систем (концепцию межпрограммного взаимодействия).
Дополнительно были рассмотрены и описаны меры, предпринимаемые в области стандартизации межгосударственного информационного обмена в рамках Евросоюза - в той части, в которой общеевропейский опыт применим на государственном уровне.
При анализе документов использовался следующий план:
1. Определялся состав документов, регулирующих стандарты в области стандартов, выяснялся их юридический статус и степень обязательности применения в госструктурах соответствующей страны
2. Изучалась структура документов, выявлялись важнейшие части, разделы, самостоятельные приложения (такие, как каталоги спецификаций и т.п.);
3. Систематизировались продекларированные принципы разработки, механизмы поддержания в актуальном (соответствующем современному технологическому уровню) состоянии и средства обеспечения исполнения рассматриваемых документов;
4. Выделялись важнейшие технологические подходы, зафиксированные в нормативно-технической документации;
5. Описывались принципы отбора и классификации стандартов;
6. Выявлялись характерные особенности и различия документов, обусловленные местной спецификой.
Выявленные общие тенденции, которые могут быть учтены и использованы при построении отечественной системы регулирования в области АПО, перечислены и проанализированы в заключительной части отчета.
Основная часть
Германия. SAGA
Область применения, статус и цели
Политика федерального правительства Германии в отношении АПО определена в документе «Standards and Architectures for e-government Applications» (SAGA, «Стандарты и архитектурные решения для приложений электронного правительства», версия 2, 2003 год). Созданием и сопровождением документа занимается Координационная и консультационная служба федерального правительства по информационным технологиям в госадминистрации (KBSt).
В качестве основных целей SAGA декларируются:
· обеспечение постоянных информационных потоков между гражданами, государством и партнёрами государства (взаимодействие);
· реализация сравнимых методов при подготовке услуг и для определения моделей данных; свободным землям и коммунам (общинам) предлагается использовать результаты разработки инициативы Bund Online 2005 (переиспользуемость);
· предоставление возможности обратиться к спецификациям в форме свободно доступной документации (открытость);
· учет новых разработок на рынке и в области стандартизации (снижение стоимости и рисков);
· обеспечение пригодности решений с учётом меняющихся требований в отношении объёмов и частоты транзакций (масштабируемость).
SAGA описывает разрешённые технические рамки разработки, коммуникации и взаимодействия IT-систем федеральных учреждений. Соответствие SAGA является принципиально обязательным для всех процессов и систем, которые задействованы в услугах электронного правительства (die E-Government-Dienstleistungen des Bundes erbringen). Для систем, не имеющих прямого интерфейса к электронному правительству, разрешена миграция, если соотношение затрат и отдачи является разумным.
Структура документации
При описании архитектуры приложений электронного правительства авторы SAGA используют Reference Model for Open Distributed Processing (RM-ODP, эталонная модель для открытой распределенной разработки, ISO 1996). Данная модель не является обязательной, но настоятельно рекомендуется для использования. Приложения электронного государства в SAGA рассматривается со следующих точек зрения:
· организационной (enterprise), описывающий общие подходы к моделированию процессов и построению информационных систем;
· информационной (information), описывающей свойства и семантику обрабатываемых данных;
· компонентной (computational), рассматривающей приложение как совокупность функциональных модулей и интерфейсов для их взаимодействия;
· инженерной (engineering), описывающей инфраструктуру, в т.ч. техническую и телекоммуникационную, необходимую для работы распределенных программных систем;
· технологической (technology), рассматривающей приложение как совокупность используемых в нем технологий.
Собственно предметом стандартизации являются технологические требования к приложениям, Концепции первых четырех представлений накладывают условия на технологические стандарты.
SAGA разработана, как новый ключевой документ в составе сводного издания документов KBSt, включающего более ранние концепции («V-модель», «Руководство по миграции», «DOMEA» и др.). Эти документы частично заменяются SAGA, а не охваченные в SAGA вопросы, освещенные в них, должны быть заново согласованы с учетом новой модели АПО, предлагаемой в SAGA. В то же время принято решение при дальнейшем написании SAGA избежать дальнейшего внесения разногласий между актуальными документами.
Организационные принципы
Подход SAGA основывается на повсеместном использовании стандартов в процессе реализации технических инициатив проекта электронного правительства Германии, которые сосредоточиваются на четырех направлениях (задачах):
· Выявлении технических нормативов, эталонов, стандартов и архитектур.
· Моделировании процессов.
· Моделировании данных.
· Создании базовых компонентов.
SAGA определяет строгую процедуру установления соответствия систем ее требованиям, включающую, в частности, декларирование соответствия разработчиками систем. Приложение для электронного правительства, удовлетворяющее требованиям SAGA, должно:
· применять стандартизированные модели процессов;
· использовать стандартизированные модели данных;
· обеспечивать совместимость с описанными в SAGA техническими стандартами и архитектурами;
· использовать существующие (ранее разработанные) базовые компоненты.
Для несоответствующих (неконформных) систем устанавливается целый ряд ограничений в использовании:
· ограничено использование базисных компонентов;
· консультационные услуги центров компетенции ограничиваются;
· интерфейсы таких систем не обслуживаются (не поддерживаются);
· субсидии, в особенности средства для инициативы BundOnline 2005, становятся невозможными;
· интеграция системы в портал www.bund.de становится невозможной.
Технологические подходы
Приложения для электронного правительства, согласно SAGA, разрабатываются в соответствии со следующими основополагающими принципами:
· приложения для электронного правительства используют в качестве фронт-энда браузер, переносимые сервисы отображаются только через браузер за исключением отдельных случаев, где это не представляется разумным;
· разработчики отказываются от использования активных компонентов, чтобы не принуждать пользователя к снижению порога безопасности в браузере, что может повлечь за собой повреждение данных пользователей из-за небезопасных веб-страниц, либо используют как минимум только подписанные и безопасные приложения в соответствии с определенными в SAGA процедурами и спецификациями;
· приложения для электронного правительства не записывают на компьютер пользователей никаких программных компонентов или данных, влекущих к потере пользователем контроля над своим компьютером.
SAGA декларирует однозначную ориентацию на открытые системы и, в частности, прямо оговаривает на необходимость отказа от использования закрытых решений Microsoft, что является довольно необычным шагом. В качестве альтернативы предусматривается использование платформ J2SP и J2EE.
В отличие от большинства других проектов в области АПО, SAGA определяет требования к приложениям не только на уровне взаимодействия, но и на уровне компонентной структуры. В качестве основной компонентной архитектуры предложена многослойная модель со средним слоем, показанная на Рис. 1.1:
|
Рис. 1 . 1 .
|
· Клиентский уровень модели представляет различные каналы доступа, различия которых обусловлены разными пользователями, терминалами, способами передачи и целями применения. В SAGA предусматриваться как минимум три канала доступа:
§ доступ пользователей через веб-браузер;
§ доступ пользователь через мобильные каналы (WAP, PDA);
§ доступ внешних систем через стандартизованные интерфейсы, в первую очередь – через веб-сервисы.
· Презентационный уровень описывает компоненты, выполняющие взаимодействие с пользователем и преобразование (трансформацию) информации к форме, пригодной для соответствующего клиента. Компонент презентации должен охватывать все стандарты коммуникации с рассмотренными на клиентском уровне терминалами.
· Средний слой (слой предметной области) описывает ядро специфичных для процессов электронного государства компонентов. В среднем слое инкапсулируется специфичная логика данной информационной системы и обрабатываются данные, получаемые из постоянного слоя. Средний слой определяется, как основной источником компонентов для повторного использования.
· Постоянный слой описывает хранение данных. Как правило, реализуется при помощи готовых СУБД. Кроме того, данный уровень является обобщающим понятием для средств операционной системы, специфичных информационных хранилищ, а также унаследованных систем, не соответствующих требованиям SAGA.
Интересным с российской точки зрения является учет в документе федеративной структуры государственных органов Германии. Организационная точка зрения SAGA устанавливает требования к налаживанию всех основных типов взаимодействия (G2С, G2B, G2G) в рамках электронного государства, при этом большое внимание уделяется взаимодействию с местными органами самоуправления.
Рекомендуемая SAGA модель взаимодействия показана на Рис. 1.2:
|
Рис. 1 . 2 .
|
Порядок отбора спецификаций
В SAGA определена достаточно сложная модель мониторинга и принятия стандартов, включающая основной каталог стандартов, в котором стандарты могут иметь следующие статусы:
· Обязательные. Стандарты являются обязательными, когда они одобрены м предоставляют предпочитаемое решение задачи. Эти стандарты рассматриваются и применяются в первую очередь. Конкурирующие стандарты могут быть одновременно обязательными, если основные задачи приложений явно различаются между собой. Если одновременно существуют обязательные и рекомендованные, либо находящиеся под наблюдением стандарты, то последние из них должны применяться лишь в обоснованных исключительных случаях. Обязательная классификация не обозначает, что стандарт применяется в каждом приложении для электронного правительства. Обязательный стандарт должен использоваться только в том случае, когда технология или функциональность, связанная со стандартом, является обязательной или желательной в контексте требований к определённому приложению.
· Рекомендованные. Рекомендация стандартов возможна в том случае, когда эти стандарты прошли проверку на надёжность, но либо не являются необходимыми (например, не обеспечивают оптимальное решение задачи), либо ещё не прошли рассмотрение в качестве обязательных стандартов. Если помимо рекомендуемых стандартов не существует конкурирующих обязательных стандартов, обоснованное отклонение от рекомендуемых стандартов возможно только в порядке исключения. Конкурирующие стандарты могут быть одновременно рекомендуемыми, если различия в их применении чётко разграничены. В таких случаях для каждого отдельного случая выбирается наиболее подходящий стандарт. В случае одновременного существования рекомендуемых и наблюдаемых стандартов последние из них могут обоснованно применяться лишь в порядке исключения.
· Под наблюдением. Стандарты находятся под наблюдением в том случае, когда они следуют в желаемом направлении развития, но при этом не являются достаточно зрелыми, либо ещё не закрепились на рынке.
Помимо классифицированных в каталоге, совместно в SAGA ведутся ещё три справочных списка стандартов, которые обзорно представляют:
· Новые, ещё не прошедшие оценку стандарты (Белый список).
· Устаревшие стандарты, от которых отказались (Чёрный список).
· Готовящиеся к введению в эксплуатацию стандарты (Серый список).
Процессы изменения статусов стандартов показаны на Рис. 1.3:
|
Рис. 1 . 3 .
|
1. Новый стандарт предлагается для включения в классификатор командой разработчиков, экспертами, участниками форума. Предложенный стандарт включается в “белый” список на сайте. Из позиции 1 возможен переход в позицию 3 за один шаг.
2. Стандарты, не прошедшие оценку и не включенные в классификатор, переносятся в “черный” список отвергнутых стандартов.
3. Стандарт с позитивными результатами тестирования добавляется в следующую версию классификатора.
4. Стандарт, вошедший со статусом «рассматриваемый» получает статус «рекомендуемый» в следующей версии классификатора.
5. Вошедший стандарт со статусом «рекомендуемый» получает статус «одобренный».
6. Стандарт, вошедший со статусом «одобренный», получает статус «рекомендуемый». Переход из 6 в 7 может быть выполнен за один шаг.
7. Стандарт, вошедший со статусом «рекомендуемый», не включается в следующую версию классификатора, а переходит в серый список.
8. Устаревшие стандарты из серого списка, которые более не используются и не поддерживаются, перемещаются в «черный» список.
9. Стандарты со статусом «рассматриваемый», которые не прошли проверку на соответствие принципам SAGA, переносятся в «черный» список.
Дата: 2019-12-10, просмотров: 240.
