ВВЕДЕНИЕ
В настоящем документе рассмотрены предпосылки, исходя из которых были разработаны документы «Архитектура программного обеспечения» и Главный профиль АПО. Документ содержит анализ текущей отечественной ситуации в области стандартизации программного обеспечения, а также описывает выводы и обобщения, полученные в ходе анализа зарубежного опыта создания АПО. Обзор источников данных для анализа приведен в Приложении 2 к пояснительной записке.
Пояснительная записка не детализирует конкретных решений, сделанных на основе приведенного в ней анализа. Соответствующие сведения приведены в документе «Архитектура программного обеспечения».
Источником для проектирования АПО являются:
очевидные потребности в защите государственных интересов, вытекающие из практического опыта, законодательства, действующей нормативно-технической документации – обеспечение эффективности и результативности процессов использования программного обеспечения в государственных информационных системах;
общие подходы к архитектуре электронного государства в целом, определенные на текущий момент.
На максимальном уровне обобщения можно выделить три основные задачи создания архитектуры программного обеспечения:
используя некоторые стандартизированные правила описать в общем виде структуру программных систем электронного государства;
на основании сделанного описания выделить функции (области), в которых необходимо применение унифицированных, единых для всех программных систем электронного государства, решений;
в соответствии с некоторыми общими принципами, обеспечивающими защиту интересов государства, произвести отбор спецификаций и стандартов, описывающих обязательные и рекомендуемые решения для тех или иных функций.
Таким образом, сущностью деятельности по созданию АПО является функциональная стандартизация (профилирование стандартов) – то есть определение базовых спецификаций в области информационных технологий и определение условий их использования с привязкой к конкретным функциям АПО.
В качестве ориентира при определении подходов к построению АПО используются:
международный опыт в аналогичной области;
международные стандарты в области создания функциональных профилей программного обеспечения.
1Обзор целей и задач АПО .1.1Предпосылки
Существующий в России корпус нормативно-технической документации, определяющий общесистемные требования в области информационных технологий, был исторически ориентирован в основном на «автоматизированные системы» (АС, см. например, ГОСТ серии 34). Программное обеспечение автоматизированных систем не выделялось особо среди прочих видов обеспечения – технического, информационного, организационного и т. п. и рассматривалось весьма ограничено, как некая рядовая сущность в рамках системы.
Разумеется, задачи стандартизации при разработке именно программного обеспечения ставились достаточно давно. В системе стандартов существует специальная серия 19, разрабатывавшаяся приблизительно в тот же период, что и серия стандартов области АСУ (серия 24, предшественник серии 34). Стандарты серии 19 регламентируют требования к Единой системе программной документации (ЕСПД). Однако, несмотря на то, что в целях ЕСПД декларируется намерение установить правила разработки и обращения программ, сама система построена по аналогии с ЕСКД и, по сути, сведена исключительно к оформлению и документированию программных изделий (что подчеркивается и ее названием). Стандарты ЕСПД разработаны в начале 70-х годов, их положения опираются в основном на опыт разработки программ для ЕС ЭВМ и ориентированы преимущественно на пакетный режим обработки данных, т.е. практически непригодны для эффективного применения сегодня.
Но еще более существенным недостатком является то, что ЕСПД, в отличие от стандартов АС (АСУ), напротив, рассматривает программы и комплексы недостаточно системно, в сильном отрыве от их назначения и условий применения. Так, ГОСТ 19.102-77, описывая стадии разработки программ, вообще не предусматривает каких-либо мероприятий по их внедрению, кроме передачи для сопровождения или изготовления. Отсутствует понятие «пользователя» программы, не поддержано методически документирование программ «непрерывного действия». Не рассмотрены в ЕСПД вопросы интеграции программ и межпрограммного взаимодействия, слабо нормированы вопросы информационного и организационного обеспечения. Предложенная степень детализации структуры программных документов недостаточна, а львиная доля внимания уделяется второстепенным по современным меркам вопросам (например, маркировке и упаковке машинных носителей).
Все это привело к тому, что ссылки на ГОСТ серии 19 из других стандартов области информационных технологий носят достаточно формальный характер. Применение программных документов, предусмотренных в ЕСПД, слабо увязано с процедурами разработки АС. Многие документы, предусмотренные, например, в ГОСТ 34.201-89, сильно пересекаются по назначению и содержанию с программными документами по ГОСТ 19. Многие понятия в стандартах не согласованы – так, например, системы управления базами данных в ГОСТ 34.602-89 отнесены к информационному, а не программному обеспечению системы, понятие «лингвистического обеспечения» по-разному определено в ГОСТ 34.003-90 и во всех прочих стандартах области АС и т.п. Анализируя всю совокупность ГОСТ серий 34 и 24, можно видеть, что упор в них в значительной степени сделан на аппаратную часть АС, под которую и должно разрабатываться программное обеспечение, документируемое по ЕСПД.
В современных условиях программное обеспечение выходит на первый план, определяя и функциональность самой системы, и требования ко всем прочим видам обеспечения. Системы перестают быть вещью в себе и нуждаются в широком взаимодействии.
Для удобства введем понятие “информационной системы”, основными отличиями которой от классической “автоматизированной системы”1 являются:
Выход на первый план понятия «пользователь системы» в противовес «персоналу»2. Пользователи системы, как правило, не подчинены владельцу системы. В информационной системе могут быть определены различные роли пользователей (технически или орагнизационно), но (в большинстве случаев) не могут быть заранее определены сами субъекты этих ролей. Заказчик, оператор и разработчик информационной системы могут регулировать (ограничивать) доступ пользователей к системе, но в большинстве случаев не могут обязать их работать с ней (для государственных систем такая обязанность может быть установлена законом, но эта мера находится уже вне компетенции АПО). На практике для информационных систем, функционирующих в Интернете, численность и характеристики («квалификация», «режим работы») потенциальных пользователей определяются с такой степенью нечеткости, что можно говорить о качественном скачке в трактовке этого понятия. Например, в новых условиях возникает необходимость перейти от формулирования задач в терминах «требований к персоналу» к терминам «целевой аудитории».
Неопределенность круга взаимодействующих “смежных систем”. Информационные системы, как правило, должны учитывать появление новых, не предусмотренных в ТЗ потребителей и поставщиков информации и сервисов. Смежные системы, как правило, находятся вне влияния владельца системы. Более того, для современных клиент-серверных систем становится не вполне определенным и отношение рабочих мест пользователей к системе – являются ли они частью системы или особым случаем смежных систем?
Потребность доступа к данным, процедурам и функциям из-за пределов системы. Процесс обработки данных (“информационная технология” по определению ГОСТ) может не целиком реализовываться в рамках одной системы.
Переносимость систем. Разработка современных систем крайне редко предполагает разработку оригинального технического обеспечения, а требования к характеристикам вычислительной техники на уровне ТЗ зачастую устанавливаются в достаточно общем виде. Представляя собой, как правило, совокупность программ и данных, информационные системы могут исполняться на различных технических средствах. Срок жизни технических средств часто оказывается меньше срока жизни самой системы, а по отношению к ее отдельным программным компонентам – наоборот, больше.
Более широкий круг «общего программного обеспечения». В классических АС под таковым обычно подразумеваются только операционная система и типовая СУБД. Информационная система, напротив, может целиком состоять из готовых программных средств, представляя собой, по сути, набор его настроек – иногда очень сложный и дорогостоящий.
Эти особенности и определяют основные потребности электронного государства в области регулирования свойств программного обеспечения, которые предполагается удовлетворить путем разработки “архитектуры программного обеспечения” – АПО:
потребность унифицированного взаимодействия с различными пользователями;
потребность унифицированного взаимодействия между информационными системами;
потребность защиты инвестиций в уже внедренные информационные системы.
Очевидными интересами (потребностями) второго уровня, вытекающими из приоритета программного обеспечения перед прочими видами обеспечения систем, являются:
устойчивый контроль государственных заказчиков за процедурами разработки программного обеспечения для их нужд;
возможность независимого от разработчика (поставщика) использования программного обеспечения, снижение затрат на тиражирование и масштабирование решений;
возможность независимого от разработчика (поставщика) развития и доработки имеющегося в распоряжении государства программного обеспечения;
возможность повторного использования компонентов программного обеспечения, выполняющих одни и те же функции с целью экономии затрат на разработку дублирующих компонентов.
.1.2Назначение и определение АПО
Исходя из перечисленных потребностей, определим архитектуру программного обеспечения (АПО) как комплекс взаимоувязанных решений по основополагающим принципам выбора технологий для создания программ в информационных системах ЭГ, а также требований к необходимым для разработки и функционирования этих программ техническим средствам и иным видам обеспечения.
С практической точки зрения АПО должна представлять комплекс стандартов и регламентов, обеспечивающих технологическую совместимость информационных систем органов государственной власти.
АПО должна стать источником требований при закупках (здесь и ниже мы относим к закупкам и разработки информационных систем по Госконтрактам) нового программного обеспечения электронного государства и интеграции разработанных ранее систем. Требования АПО должны обеспечить защиту интересов государства при:
создании новых информационных систем;
интеграции унаследованных информационных систем, разработанных до принятия АПО;
организации и поддержке информационного взаимодействия субъектов электронного государства.
Вместе с тем АПО не определяет общих принципов построения, функционирования и функционального взаимодействия систем электронного государства, методологию использования ИКТ в государственном управлении. Это является более высокоуровневыми задачами, которые являются источниками для построения АПО и должны решаться в рамках концептуального проектирования электронного государства.
Общая стратегия практического воплощения АПО в жизнь предполагает эволюционный путь развития, то есть построение АПО на основе уже существующих программных систем посредством их последовательной модернизации и интеграции на базе новых принципов и стандартов.
.1.3Анализ международного опыта
Зарубежный опыт в области функциональной стандартизации для нужд электронного государства являлся основным ориентиром при разработке архитектуры программного обеспечения, описанной в настоящей работе. В ходе разработки отечественной модели АПО были проанализированы нормативно-технические документы соответствующего назначения, применяемые в следующих странах:
Австралия;
Великобритания;
Германия;
Гонконг;
Дания;
Египет;
Новая Зеландия;
США.
Кроме того, анализировался специфический опыт Европейского Союза.
Как правило, в большинстве проанализированных систем функциональной стандартизации упор делается на описание среды взаимодействия (interoperability framework, IF) государственных информационных систем друг с другом и с гражданами-пользователями.
Более глубоко и широко архитектура ПО рассматривается в Германии и США, где в дополнение к задачам взаимодействия рассмотрена также компонентная структура приложений. Обе этих концепции используют систему эталонных функциональных моделей для описания архитектуры электронного государства. Наибольшего успеха в претворении компонентной АПО в жизнь достигла Германия, что можно объяснить весьма прагматическим подходом к использованию стандартизованных моделей.
Общими чертами всех документов в области АПО являются (без ранжирования):
обязательный характер как минимум части положений АПО при разработке информационных систем для нужд государства;
наличие сводного каталога базовых спецификаций, использующего систему статусов для определения условий использования и жизненного цикла стандартов;
приоритет международных стандартов над национальными, активное использование международного опыта, глобализация решений;
ориентация на открытые системы и стандарты, вплоть до декларирования полного отказа от проприетарных решений в достаточно близкой перспективе;
публичный характер документов в области АПО, в большом числе случаев – публичные процедуры их подготовки;
использование XML в качестве метаязыка для моделирования информационных структур и обмена данными;
ориентация на взаимодействие и использование интернет-технологий, в т.ч. определение веб-браузера в качестве основного клиента для государственных информационных систем при взаимодействии с гражданами и веб-сервисов при межсистемном взаимодействии;
разработка собственных расширений существующих стандартов в области метаданных для специфических нужд электронного государства;
заметное внимание, уделяемое проблемам обеспечения совместимости с унаследованными системами, выбывающим стандартам, и процедурам миграции.
Большинство рассмотренных документов в области IF весьма схожи, что естественно в условиях нарастающей глобализации и при использовании одного и того же корпуса международных стандартов и технологий. Наиболее характерные примеры стандартизации в области АПО рассмотрены в Приложении 2 к настоящей пояснительной записке – пналитическом отчете “Анализ международного опыта в стандартизации АПО”.
.1.4Проблемы развития АПО. Ограничения текущей версии
Задача описания архитектуры программного обеспечения является чрезвычайно сложной и комплексной. Основными факторами, препятствующими ее полномасштабному решению, являются:
Недостаточная проработанность и формализованность задач электронного государства в целом. Принятые в настоящий момент концепции ЭГ носят не архитектурный, а организационно-распорядительный характер, и не позволяют построить на их основе целостную функциональную модель, необходимую для непротиворечивого описания пространства стандартизованных спецификаций.
Неготовность государственной машины к внедрению сервис-ориентированных информационных систем. В настоящий момент насущным является не столько взаимодействие с гражданами, сколько упорядочивание информационных потоков между самими государственными ведомствами.
Общий слабый уровень концептуальной и управленческой подготовки как персонала государственных ведомств, так и разработчиков информационных систем. Потенциальные пользователи АПО просто не владеют необходимым терминологическим аппаратом в области архитектурного моделирования. К тому же существуют проблемы и с переводом терминов: многие устоявшиеся в международной практике выражения не имеют общепринятых и лишенных побочных коннотаций эквивалентов в русском языке.
Следует отметить, что в полной мере задача построения целостной, непротиворечивой и системно развивающейся модели АПО не решена и нигде в мире: Так, например:
Американский Офис Управления Программой Архитектуры Федерального Предприятия (FEA-PMO) в своем ежегодном послании признает проблемы с внедрением компонентной архитектуры в федеральных агентствах и скептическое отношение к возможности получения прогнозируемых выгод и преимуществ со стороны целого ряда правительственных агентств.
Немецкий документ SAGA устанавливает в качестве безусловно приоритетной модели описания систем модель распределенной обработки ODP-PMI, но на практике в текущей версии SAGA достаточно широко освоен только подход «пяти точек зрения», что составляет менее четверти всех идей и подходов, предложенных в ODP.
Великобритания одной из первых стран в мире приступила к проекту построения стандартизированной среды взаимодействия путем составления каталога обязательных к применению стандартов и в меньшей степени, чем другие страны, ориентируется на использование эталонных моделей, используя свою, построенную в значительной степени эмпирическим путем, таксономию спецификаций. Косвенным следствием недостаточно системного подхода к каталогу можно считать тот факт, что до сих пор, уже в шестой версии документа, определения ряда спецификаций содержат фактические ошибки (неверные ссылки и номера стандартов) и противоречия.
С учетом всего вышесказанного, в текущей версии АПО разработчик не ставил перед собой задачи достичь «идеальной» модели АПО. Ряд перспективных концептуальных идей был намеренно упрощен с целью облегчения практического использования документов, часть оставлена за пределами рассмотрения, так как нуждается в длительном дополнительном изучении и увязке с прочими элементами архитектуры электронного государства.
В то же время в целях будущего развития предлагается иметь в виду более строгое определение АПО, как модели интегрированной среды информационных сервисов электронного государства, характеризующихся:
непрерывностью – физической доступностью сервисов АПО в любой момент времени и в любой точке географического пространства России;
простотой доступа – реализуемого посредством использования специализированных информационных устройств ввода/вывода нового поколения;
доступностью сервисов АПО, прежде всего по стоимости;
гарантированностью обеспечения требуемого качества обслуживания и защиты информации при использовании сервисов АПО;
обширным спектром прикладных сервисов, охватывающих все имеющиеся виды информации: аудио, видео, графическую, динамическую графику, данные, документы гипертекста и мультимедиа;
функционированием на основе достижения широкого согласия по общим принципам управления доступом к сервисам АПО, основанного на бесшовном соединении взаимосвязанных, интероперабельных компонентов АПО.
Важной особенностью сервисов АПО является их согласованность, целостность и законченность, в том смысле, что они определяют законченные сценарии предоставления сервиса конечному пользователю.
В заключительном разделе настоящей пояснительной записки рассмотрена некоторая будущая целевая модель – модель развития АПО исходя из предложенного выше расширенного определения. Эта модель основана на анализе наиболее прогрессивных разработок международных стандартизующих организаций, в первую очередь Совета по Стандартизации в области Информационных и Коммуникационных Технологий (ICTSB – Information and Communications Technologies Standards Board), который реализует наиболее комплексный подход к проблематике данной области и объединяет опыт многих международных и национальных стандартизирующих организаций. Предложенная модель развития может быть реализована по мере возрастания готовности российского электронного государства.
|
