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

Основы методологии проектирования профилей
Рекомендации по стандартизации РФ Р50.1.041-2002 "Информационные технологии. Руководство по проектированию профилей среды открытой системы (СОС) организации-пользователя". В Рекомендациях реализован подход к профилям с точки зрения их жизненного цикла (ЖЦ). Для функциональной стандартизации в информационных технологиях служит стандарт ГОСТ Р ИСО/МЭК ТО 1000.
Одним из наиболее эффективных является использованный в Рекомендациях подход, предусматривающий декомпозицию функциональных служб ИС на простые службы информационных технологий (ИТ), для которых, в свою очередь, сравнительно легко идентифицировать базовые стандарты, их опции, временные решения и т.п. Практическая реализация требует разработки модели, дающей абстрактное описание среды ИС в терминах сущностей и служб, причем это описание не должно быть связано с конкретным техническим обеспечением системы.
Такие модели известны как эталонные (reference models) .

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

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

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

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

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

Процессы жизненного цикла
профилей. Логический и физический проекты профиля
Первым шагом на этапе собственно проектирования является (Рис. 2) логический проект профиля. В рамках логического проекта выделяются службы ИТ, необходимые для обеспечения служб ИС. Отношения между службами ИС и службами ИТ также являются отношениями вида "многие ко многим". Для определения взаимосвязи между службами ИС и службами ИТ нужна эталонная модель OSE/RM.
Эталонная модель OSE/RM определяет четыре главных категории служб среды открытой ИС:
интерфейс человек-компьютер (ИЧК);
системная;
информационная;
коммуникационная .

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

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

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