Информационное общество и компоненты информационного менеджмента

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

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

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

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

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

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

Эти услуги определены в составе многомерных графических объектов и изображений в независимой от устройства форме.

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

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

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

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

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

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

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

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

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

Федеральные стандарты по обработке данных (FIPS) правительства США.Они одобряются и публикуются согласно положениям раздела 111 (d) Акта о федеральной собственности и административных службах от 1949 г. с учетом уточнений, внесенных Актом защиты компьютеров от 1987 г. К стандартам FIPS относятся стандарты, руководства и технические методики, разработанные национальным институтом стандартов и технологий (NIST), одобренные Министерством торговли и изданные для правительственного пользования.

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

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

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

Стандарт FIPS определяет, необходимо ли тестирование конкретных реализаций для подтверждения их соответствия этому стандарту. Порядок (протокол) тестирования для реализации стандарта разработан лабораторией CSL. В каждом конкретном случае порядок тестирования создается с таким расчетом, чтобы были отражены специфические требования конкретного стандарта F1PS. Порядок тестирования определяет:

· требования, выполнение которых должно проверяться при тестировании;

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

· способ трактовки безуспешных результатов тестирования.

Национальная добровольная лаборатория аккредитации программ (NVLAP) - организация в рамках института NIST - аккредитует лаборатории на выполнение тестирования по различным программам. Требования к аккредитации строго определены и различны для каждого стандарта. В общем случае повторная аккредитация происходит каждые два года.

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

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

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

По существу, регистрация изделий - это подтверждение самими изготовителями соответствия изделия стандартам FIPS.

Перечень VPL обновляется и публикуется через лабораторию вычислительных систем (CSL) в виде отчетов NISTIRнесколько раз в году. На Перечень можно подписаться через Национальную службу технической информации (NTISPB94-937304/AS). Он также доступен в электронном виде в каталоге WordPerfect 5.1 через FTP speckle.ncsl.nist.gov (IP адрес 129.6.59.2), в каталоге vpl или в текстовом файле WorldWide Web URL: http://spe-ckle.nc-sl.nist.gov/~ka-iley/in-tro.htm. Заметим, что изделия, проверенные на соответствие как реализации, не могут быть перечислены в Перечне VPL из-за ограниченности этой информации у поставщиков.

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

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

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

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

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

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

Учитывая то обстоятельство, что Госпрофиль ВОС отражает в концентрированном виде техническую политику государства в области ВОС, Московским научно-исследовательским центром (МНИЦ) - головной организацией по стандартизации в области информатизации Госкомтелекома России были разработаны первая, а затем вторая версии “Государственного профиля взаимосвязи открытых систем. Рекомендации по стандартизации” на базе семиуровневой эталонной модели ВОС, принятые и введен ные в действие Постановлением Госстандарта России от 26 января 2000 г. ? 15-ст.

Одновременно в МНИЦ ведутся работы по созданию Государственного профиля переносимости прикладных программ.

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

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

3. Профили информационных систем для информационного менеджмента

3.1 Цели и принципы формирования профилей

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

· несколько сотен разработанных международных и национальных стандартов неполностью и неравномерно покрывают потребности в стандартизации объектов и процессов создания и применения сложных ИС;

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

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

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

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

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

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

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

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

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

Основными целями применения профилей при создании и применении ИС являются:

· снижение трудоемкости, длительности, стоимости и улучшение других технико-экономических показателей проектов ИС;

· повышение качества разрабатываемых или применяемых покупных компонентов и ИС в целом при их разработке, приобретении, развитии и модернизации;

· обеспечение расширяемости ИС по набору прикладных функций и масштабируемости в зависимости от размерности решаемых задач;

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

· обеспечение переносимости прикладного программного обеспечения между разными аппаратно-программными платформами.

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

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

В качестве методологической базы построения и применения профилей сложных распределенных ИС предлагается использовать ГОСТ Р ИСО/МЭК ТО 10000-1, 2-99 “Информационная технология. Основы и таксономия профилей международных стандартов”: Часть 1 “Общие положения и основы документирования”; Часть 2 “Принципы и таксономия профилей взаимосвязи открытых систем”; Часть 3 “Принципы и таксономия профилей среды открытой системы”, определяющую основы и таксономию профилей среды открытых систем, предлагается использовать при построении и применении профилей ИС как документ прямого применения. Эталонная модель среды открытых систем (OSE/RM) определяет разделение любой информационной системы на приложения (прикладные программы и программные комплексы) и среду, в которой эти приложения функционируют. Между приложениями и средой определяются стандартизованные интерфейсы (ApplicationProgramInterface- API), являющиеся необходимой частью профилей любой открытой системы. Кроме того, в профилях ИС могут быть определены унифицированные интерфейсы взаимодействия прикладных программ (функциональных частей) между собой и интерфейсы взаимодействия между компонентами среды ИС. В соответствии с определениями профиля и базовых стандартов, входящих в профиль, по ГОСТ Р ИСО/МЭК ТО 10000 спецификации выполняемых функций и интерфейсов взаимодействия могут быть оформлены как профиль каждого компонента системы. Таким образом, профили ИС как сложной системы с иерархической структурой могут включать в себя: стандартизованные описания функций, выполняемых данной системой, и взаимодействия с внешней для нее средой, стандартизованные интерфейсы между приложениями и средой ИС и профили отдельных функциональных компонентов, входящих в систему.

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

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

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

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

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

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

· опубликовать профиль и (или) продвигать его по формальным инстанциям для дальнейшего распространения.

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

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

· проектирование ИС, когда определяется ее архитектура и структура и соответственно уточняются положения, параметры и адаптируются стандарты комплекта профилей; они дополняются ведомственными нормативными документами; оформляются проекты документов и методических руководств по применению рабочей версии каждого профиля;

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

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

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

При сертификации информационных систем как специальный вид испытаний следует выделять сертификацию на соответствие профилям:

· процессов жизненного цикла ИС и ее компонентов;

· объектов ИС, подготовленных и рекомендуемых для эксплуатации и сопровождения.

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

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

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

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

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

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

В приложении 1 излагается номенклатура и дается краткое описание стандартов единой системы программной документации (ЕСПД); комплекса стандартов и руководящих документов на автоматизированные информационные системы (серия 34); комплекс межгосударственных стандартов стран СНГ в области документирования программных средств и описания их жизненного цикла.

3.2 Структура и содержание профилей

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

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

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

· планируется создание новой ИС в условиях отсутствия задела по системе и компонентам данного проекта;

· имеется типовой проект ИС и предстоит его адаптация и реализация;

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

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

· определение целей, которые предполагается достичь применением данного профиля;

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

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

· сводку требований к ИС или к ее компонентам, определяющим их соответствие профилю, и требований к методам тестирования соответствия;

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

· информационные ссылки на все исходные документы.

Процессы, выполняемые на протяжении жизненного цикла ИС, могут быть разбиты на три группы:

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

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

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

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

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

· профиль среды ИС;

· профиль защиты информации в ИС;

· профиль инструментальных средств, встроенных в ИС.

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

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

· прикладного программного обеспечения;

· жизненного цикла прикладных программ;

· обеспечения качества прикладных программ;

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

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

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

· выбор готовых программных и аппаратных средств, соответствующих профилям;

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

· разработка требований к методам тестирования компонентов ИС на соответствие функциональным профилям, выбор или разработка тестов соответствия;

· тестирование компонентов ИС на соответствие профилям или проверка сертификатов соответствия для применяемых готовых программных и аппаратных средств;

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

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

Международные стандарты, регламентирующие жизненный цикл сложных ИС, в настоящее время отсутствуют, поэтому ниже представлены методические рекомендации по разработке и применению профиля жизненного цикла в проектах конкретных ИС, основанные на стандарте ИСО/МЭК 12207:1995 “Информационные технологии. Процессы жизненного цикла программного обеспечения”. Такой подход правомерен постольку, поскольку программное обеспечение составляет большую часть стоимости и трудозатрат на создание современных ИС, а продолжительность жизненного цикла программного обеспечения фактически определяет продолжительность жизненного цикла ИС. Кроме того, современные методы создания программного обеспечения; переносимого между разными аппаратно-программными платформами, позволяют уменьшить зависимость жизненного цикла ИС от жизненного цикла технических средств.

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

Профиль среды ИС должен определять ее архитектуру в соответствии с выбранной моделью распределенной обработки данных: моделью DCE (Distributed Computing Environment) илимоделью CORBA (Common Object Request Broker Architecture). В первом случае модель определяется стандартами консорциума OSF, в частности механизма удаленного вызова процедур RPC (RemoteProcedureCall) с учетом стандартов де-факто, специфицирующих применяемые мониторы транзакций (например, монитор транзакций Tuxedo). Во втором случае модель определяется стандартами консорциума OMG, в частности спецификацией брокера объектных запросов ORB (ObjectRequestBroker). Стандарты интерфейсов приложений со средой ИС - API (ApplicationProgramInterface) должны быть определены по функциональным областям профилей ИС. Декомпозиция структуры среды функционирования ИС на составные части, выполняемая на стадии эскизного проектирования, позволяет детализировать профиль среды ИС по функциональным областям эталонной модели OSE/RM [41]:

· графического пользовательского интерфейса (например, стандарт Motif консорциума OSF или стандарт X Window IEEE);

· реляционных или объектно-ориентированных СУБД (например, стандарт языка SQL-92 и спецификации доступа к разным базам данных);

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

· телекоммуникационной среды в части услуг и сервисов прикладного уровня: электронной почты (по рекомендациям ITU-T X.400, Х.500), доступа к удаленным базам данных RDA (по стандарту ГОСТ Р ИСО/МЭК 9594-1 “Информационные технологии. Взаимосвязь открытых систем. Справочник. Часть 1. Общее описание принципов, моделей и услуг”), передачи файлов, доступа к файлам и управления файлами (по стандарту ГОСТ Р ИСО/МЭК МФС 10607 - 1, 2, 3, 5, 6 “Информационные технологии. Функциональный стандарт. Профили AFTnn. Передача файлов, доступ к файлам, управление системами файлов. Части 1, 2, 3, 5, 6”).

Профиль среды распределенной ИС должен включать стандарты протоколов транспортного уровня (по ISO OSI или стандарт де-факто протокола TCP/IP), стандарты локальных сетей (например, стандарт Ethernet IEEE 802.3 или стандарт Fast Ethernet IEEE 802.3 и), а также стандарты средств сопряжения проектируемой ИС с сетями передачи данных общего назначения (например, по рекомендациям ITU-T X.25, Х.З, Х.29 и др.).

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

Профиль защиты информации в ИС должен обеспечивать реализацию политики информационной безопасности, разрабатываемой в соответствии с требуемой категорией безопасности и критериями безопасности, заданными в ТЗ на систему [20]. Построение профиля защиты информации в распределенных системах клиент-сервер методически связано с точным определением компонентов системы, ответственных за те или иные функции, сервис и услуги, и функций защиты информации, встроенных в эти компоненты. Функциональная область защиты информации включает в себя функции защиты, реализуемые разными компонентами ИС:

· функции защиты, реализуемые операционной системой;

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

· функции управления данными, реализуемые СУБД;

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

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

· функции администрирования средств безопасности.

Основополагающим документом в области защиты информации в распределенных системах являются рекомендации Х.800, принятые МККТТ (сейчас ITU-T) в 1991 г. Подмножество указанных рекомендаций должно составлять профиль защиты информации в ИС с учетом распределения функций защиты информации по уровням концептуальной модели ИС и взаимосвязи функций и применяемых механизмов защиты информации. При применении профиля защиты информации в процессе проектирования, разработки и сопровождения ИС целесообразно использовать методические рекомендации, изложенные в интерпретации “Оранжевой книги” национального центра компьютерной безопасности США для сетевых конфигураций. Профиль защиты информации должен включать указания на методы и средства обнаружения в применяемых аппаратных и программных средствах недекларированных возможностей (“закладных” элементов и вирусов), указания на методы и средства резервного копирования информации и восстановления ее при отказах и сбоях аппаратуры системы.

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

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

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

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

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

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

· ведением баз данных системы;

· восстановлением работоспособности системы после сбоев и аварий.

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

· функциональное тестирование приложений;

· тестирование интерфейсов пользователя;

· системное тестирование;

· тестирование серверов и клиентов при максимальной нагрузке.

3.3 Процессы формирования,развития и применения профилей

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

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

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

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

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

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

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

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

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

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

Применение профиля защиты информации на стадии детального проектирования ИС заключается в том, чтобы структурировать распределение функций защиты и реализующих их механизмов между компонентами системы, которые определяются при детализации ее структуры. Каждой группе функций профиля защиты информации должны отвечать конкретные компоненты системы, ответственные за выполнение этих функций. Различия в уязвимости разных компонентов по отношению к внешним и внутренним негативным воздействиям, влияющим на информационную безопасность, определяют различные требования к этим компонентам. Конкретизировать требования к компонентам ИС в части защиты информации необходимо на основе стандартов, включаемых в профиль защиты информации с их адаптацией к условиям конкретной ИС и принятой политике информационной безопасности. В части услуг и механизмов защиты при передаче информации следует применять стандарт ГОСТ Р ИСО/МЭК 7498-2-99 “Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель”. Часть 2 “Архитектура защиты информации”, определяющий набор факультативных услуг и механизмов защиты по уровням эталонной модели ВОС. Конкретизацию требований к прикладным процессам по функциям аутентификации следует проводить с учетом стандарта ГОСТ Р ИСО/МЭК 9594-8-98 “Информационная технология. Взаимосвязь открытых систем”. Часть 8 “Основы аутентификации”. Компоненты ИС, реализующие механизмы цифровой подписи, должны соответствовать требованиям ГОСТ 28147-89 “СОИ. Защита информации. Алгоритм криптографической подписи”.

...