Р 50.1.041-2002

Информационные технологии

РУКОВОДСТВО ПО ПРОЕКТИРОВАНИЮ
ПРОФИЛЕЙ СРЕДЫ ОТКРЫТОЙ
СИСТЕМЫ (СОС)
ОРГАНИЗАЦИИ-ПОЛЬЗОВАТЕЛЯ

 

ГОССТАНДАРТ РОССИИ
Москва

 

Предисловие

1 РАЗРАБОТАНЫ Институтом радиотехники и электроники Российской Академии Наук (ИРЭ РАН), Московским государственным институтом радиотехники, электроники и автоматики (Технический университет) и Всероссийским научно-исследовательским институтом стандартизации (ВНИИстандарт) Госстандарта России

ВНЕСЕНЫ Техническим комитетом по стандартизации ТК 22 «Информационные технологии»

2 ПРИНЯТЫ И ВВЕДЕНЫ В ДЕЙСТВИЕ Постановлением Госстандарта России от 14 ноября 2002 г. № 415-ст

3 ВВЕДЕНЫ ВПЕРВЫЕ

СОДЕРЖАНИЕ

Введение

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

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

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

Настоящие рекомендации по стандартизации разработаны с учетом требований стандарта IEEE Std 1003.23-98 «Стандарт института инженеров по электротехнике и электронике. Руководство по проектированию профилей среды открытой системы организации-пользователя» [1] и предназначены оказывать содействие пользователям, проектировщикам, заказчикам и специалистам по применению и эксплуатации сложных информационных систем при создании профилей СОС организации-пользователя, которые устанавливают требования организаций к обработке информации и телекоммуникациям. В зависимости от целого ряда факторов, включая функции, процессы и задачи, выполняемые организацией, может быть принят различный подход к проектированию профилей СОС. Настоящие рекомендации не содержат всех необходимых сведений для создания профиля СОС, они устанавливают методологию выбора стандартов и процедуры проектирования профилей СОС организации-пользователя и при практическом применении должны быть дополнены другими технологиями, имеющими отношение к созданию профилей СОС с учетом специфики конкретной организации.

Р 50.1.041-2002

Информационные технологии

РУКОВОДСТВО ПО ПРОЕКТИРОВАНИЮ ПРОФИЛЕЙ СРЕДЫ
ОТКРЫТОЙ СИСТЕМЫ (СОС) ОРГАНИЗАЦИИ-ПОЛЬЗОВАТЕЛЯ

Дата введения 2004-01-01

1 Область применения

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

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

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

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

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

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

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

Настоящие рекомендации не являются руководством по проведению аттестационного тестирования профилей СОС и не устанавливают методы тестирования профилей СОС организации-пользователя.

2 Нормативные ссылки

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

ИСО/МЭК МФС 11183-1-92^*) Информационная технология. Международные функциональные стандарты AOMln управления ВОС. Управление коммуникациями. Часть 1. Спецификация элемента услуги управления связью, протоколов уровней представления и сеанса, используемых элементами услуги удаленного доступа и управления связью

ИСО/МЭК 14252-95^*) Информационная технология. Руководство по среде открытых систем для POSIX

^*) Оригинал - во ВНИИКИ Госстандарта России.

3 Определения, сокращения и обозначения

3.1 Определения

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

3.1.1 аккредитованная организация - разработчик стандартов (accredited standards development organization): Организация, признанная в качестве организации - разработчика стандартов международным органом по стандартизации (например ИСО, МЭК или МСЭ-Т) или одним из полномочных членов этих организаций (например национальным органом по стандартизации, таким как Госстандарт России).

3.1.2 профиль прикладной среды (application environment profile): Комбинация многих стандартов, а также стандартных профилей, которая определяет различные типы функциональных возможностей, необходимых для конкретной среды.

3.1.3 прикладная платформа (application platform): Набор ресурсов, включая технические и программные средства, обеспечивающий услуги для работы прикладного программного средства.

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

3.1.4 прикладное программное средство (application software): Программное средство, предназначенное для приложения и состоящее из программ, данных и документации.

3.1.5 прикладной программный интерфейс (ППИ) (application program interface (API)): Интерфейс между прикладным программным средством и прикладной платформой, через который обеспечивается доступ ко всем необходимым службам (услугам).

3.1.6 базовый стандарт (base standard): Принятый международный стандарт, технический отчет, рекомендация МСЭ-Т или национальный стандарт.

3.1.7 направления деятельности (НД) (домен) (business area (BA) (domain)): Логическое выделение из всей деятельности предприятия сходных направлений, например финансовой деятельности, деятельности по продажам и маркетингу.

3.1.8 целевая функция (business function): Набор процессов, обеспечивающих достижение конкретной цели деятельности.

3.1.9 требование к бизнес-системе (ТБС) (business system requirement (BSR)): Устанавливаемое предприятием требование к системе, то есть набор процессов, процедур и документации, обеспеченный соответствующей технологией, регламентирующее коэффициент критичности успеха (ККУ) или ключевой показатель эффективности (КПЭ) при достижении цели или вида деятельности предприятия.

3.1.10 интерфейс коммуникационной службы (ИКУ) (communications services interface (CSI)): Граница, через которую обеспечивается доступ к службам при взаимодействии между внутренними объектами прикладного программного средства и внешними объектами прикладной платформы.

3.1.11 профиль компонента (component profile): Профиль, образуемый путем формального определения подмножества единственного стандарта.

3.1.12 коэффициент критичности успеха (ККУ) (critical success factor (CSF)): Мера эффективности деловой системы, которая в совокупности с другими ККУ образует КПЭ.

3.1.13 фактический стандарт (de facto standard): Стандарт, разработанный неофициально, когда один или несколько субъектов создают продукцию или технологию, которые имеют спрос и копируются, становясь так широко используемыми, что отклонение от их исходных образцов вызывает проблемы с совместимостью или ограничивает конкурентоспособность.

3.1.14 создаваемый стандарт (emerging standard): Технические требования (спецификация), представленные на рассмотрение аккредитованной организацией, разрабатывающей стандарты, но еще не прошедшие процесс принятия компетентным органом.

3.1.15 внешняя среда (external environment): Набор объектов, внешних по отношению к прикладной платформе, с которой обеспечивают взаимодействие различные службы организации.

К внешним объектам относятся персонал, сменные носители, не установленные в платформе, линии связи и другие платформы.

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

 - интерфейс человек-компьютер (ИЧК);

 - информация;

 - коммуникации.

3.1.17 функциональное качество (ФК) (functional quality (FQ)): Мера уровня службы (услуги) и эффективности (производительности), предполагаемая при обеспечении выполнения ТБС с помощью предложенного технологического решения. Данные ФК допускается использовать в качестве критериев оценки эффективности и для аттестационного тестирования, а также для выбора стандартов при реализации проекта на физическом уровне и изделий при переводе проекта на физическом уровне в реализуемое (эксплуатационное) решение.

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

3.1.19 гармонизация (harmonization): Процесс, обеспечивающий исключение дублирования и непротиворечивость стандартов (включая профили).

3.1.20 интерфейс человек-компьютер (ИЧК) (human/computer interface (HCI)): Граница, через которую реализуется физическое взаимодействие человека с прикладной платформой.

3.1.21 служба информационных систем (ИС) (information systems (IS) service): Высокоуровневое описание служб, применяемых для реализации ТБС. Службы ИС дают перекрестные ссылки на ТБС, которые они обеспечивают, службы ИТ, которые их обеспечивают, и технологические компоненты, вмещающие данные службы.

3.1.22 службы информационной технологии (ИТ) (information technology (IT) service): Самый неделимый уровень технологии. Группа служб ИТ взаимодействует для обеспечения служб ИС, поддерживающих ТБС. Службы ИТ описываются в терминах протоколов, ППИ и компонентов служб.

3.1.23 модель служб информационной технологии (ИТ) (information technology (IT) service model): Текстовое и графическое представление служб ИТ, определяющее все низкоуровневые компоненты и интерфейсы служб.

3.1.24 информационный (informative): По ИСО/МЭК 14252.

3.1.25 интерфейс (interface): Общая граница между двумя функциональными объектами, требования к которой определяются стандартом.

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

3.1.26 функциональная совместимость (interoperability): Способность двух или более систем обмениваться информацией и использовать эту информацию.

3.1.27 ключевой показатель эффективности (КПЭ) (key performance indicator (KPI)): Показатель эффективности конкретной бизнес-системы, выраженный в терминах целей и задач предприятия.

3.1.28 местный(е) (locale(s)): Определение среды пользователя в зависимости от языка и культурных обычаев.

3.1.29 нормативный (normative): Обязательный набор инструкций или ссылок.

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

3.1.31 открытая система (open system): Система, реализующая достаточно открытые спецификации или стандарты для интерфейсов, служб и форматов, облегчающая прикладному программному средству:

 - перенос его с минимальными изменениями в широком диапазоне систем, использующих продукты разных производителей (поставщиков);

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

 - взаимодействие с людьми в стиле, облегчающем переносимость пользователя.

3.1.32 среда открытой системы (СОС) (open system environment (OSE)): Исчерпывающий набор интерфейсов, служб и форматов совместно с пользовательскими аспектами, необходимый для обеспечения функциональной совместимости или переносимости приложений, данных или персонала в соответствии со стандартами и профилями ИТ.

3.1.33 профиль среды открытой системы (СОС) (open system environment (OSE) profile): Выбранный набор стандартов и их вариантов (опций), определяющий поведение интерфейсов для конкретного класса или области приложений в терминах функциональных вызовов, протоколов, форматов данных и т.д.

3.1.34 предложенное решение (point solution): Предложенная архитектура систем, достаточно конкретизированная для определения возможности удовлетворения требований и стоимости их реализации.

3.1.35 переносимость (прикладного программного средства) (portability (application software)): Степень легкости, с которой прикладные программные средства и данные могут быть перенесены с одной прикладной платформы на другую.

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

3.1.37 функциональный стандарт POSIX (POSIX ФС) (standardized profile (POSIX SP)): Функциональный стандарт, специфицирующий применение определенных базовых стандартов POSIX для обеспечения класса приложений и полностью соответствующий эталонной модели, определенной в ИСО/МЭК 14252.

3.1.38 профиль (profile): Набор из одного или нескольких базовых стандартов с указанием, при необходимости, выбранных классов, подмножеств, опций базовых стандартов, необходимых для выполнения конкретной функции. См. также профиль прикладной среды (3.1.2), функциональный стандарт POSIX (3.1.37) и профиль СОС системы организации-пользователя (3.1.53).

3.1.39 протокол (protocol): Набор семантических и синтаксических правил, определяющий поведение взаимодействующих объектов.

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

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

3.1.42 путеводитель (road map): Общая схема процесса.

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

3.1.44 служба (услуга) (service): Отдельная часть функциональной возможности объекта, которая предоставляется объектом на одной стороне интерфейса объекту на другой стороне интерфейса.

3.1.45 соединители (sockets): Интерфейс транспортного протокола.

3.1.46 программное средство (software): Программы, процедуры, правила и любая соответствующая им документация, имеющие отношение к эксплуатации системы обработки информации.

3.1.47 технические требования (спецификация) (specification): Документ, устанавливающий законченным, точным, поддающимся проверке способом требования к системе или компоненту системы, их проект, поведение или характеристики.

3.1.48 стандарт (standard): По ИСО/МЭК 14252.

3.1.49 функциональный стандарт (standardized profile): Прошедший процедуру голосования, официальный, гармонизированный документ, определяющий профиль.

3.1.50 технология (technology): Научные знания, используемые для достижения практической цели.

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

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

3.1.53 профиль СОС организации-пользователя (user organization OSE profile): Профиль, документально оформленный в терминах стандартов открытой системы (3.1.31), функциональных стандартов POSIX (3.1.37), функциональных стандартов (3.1.49) и (или) промежуточных технологий или изделий, которые необходимы в качестве основы инфраструктуры при принятии решений по удовлетворению деловых потребностей предприятия.

3.2 Сокращения

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

АВПР (САМ) - автоматизированное производство (Computer-Aided Manufacture);

АПР (CAD) - автоматизированное проектирование (Computer-Aided Design);

АПС (МТА) - агент передачи сообщения (Message Transfer Agent);

АСКИ (ASCII) - американский стандартный код для информационного обмена (American Standard Code for Information Interchange);

БД (DB) - база данных (Database);

БДН (MAU) - блок доступа к носителю (Media Access Unit);

БУИ (MIB) - база управленческой информации (Management Information Base);

BOC (OSI) - взаимосвязь открытых систем (Open System Interconnection);

ВТК (VTC) - видео-телеконференция (Video Teleconferencing);

ГВС (WAN) - глобальная вычислительная сеть (Wide Area Network);

ГИП (GUI) - графический интерфейс пользователя (Graphical User Interface);

ЦУБД (RDA) - доступ к удаленной базе данных (Remote Database Access);

ЕВРО (ECU) - европейская денежная единица (European Currency Unit);

ECOC (EWOS) - европейский семинар по открытым системам (European Workshop on Open Systems);

ЗHK (RFC) - запросы на комментарий (Request For Comments);

ИВС (EEI) - интерфейс с внешней средой (External Environment Interface);

ИГУ (GDI) - интерфейс графического устройства (Graphics Device Interface);

ИКУ (CSI) - интерфейс коммуникационных услуг (Communications Services Interface);

ИП (UI) - интерфейс пользователя (User Interface);

ИС (IS) - информационные системы (Information Systems);

ИСГО (IGES) - исходная спецификация графического обмена (Initial Graphics Exchange Specification);

ИТ (IT) - информационная технология (Information Technology);

ИЧК (HCI) - интерфейс человек-компьютер (Human/Computer Interface);

ККУ (CSF) - коэффициент критичности успеха (Critical Success Factor);

ОАПЗО (КОРБА)^*) (CORBA) - общая архитектура посредника запросов к объектам (Common Object Request Broker Architecture);

КПЭ (KPI) - ключевой показатель эффективности (Key Performance Indicator);

ЛВС (LAN) - локальная вычислительная сеть (Local Area Network);

MKKTT (CCITT) - Международный консультативный комитет по телефонии и телеграфии, см. МСЭ-Т (Consultative Committee on International Telephony and Telegraphy);

ММГ (CGM) - метафайл машинной графики (Computer Graphics Metafile);

MPA (ADM) - метод разработки архитектуры (Architecture Development Method);

МСЭ-Т (ITU-T) - Международный союз электросвязи - бюро телекоммуникационных стандартов (International Telecommunication Union Telecommunication Standards Bureau);

МФС (ISP) - международный функциональный стандарт (International Standardized Profile);

НД (BA) - направления деятельности (Business Area);

ОГИ (CGI) - общий графический интерфейс (Common Graphical Interface);

ОПС (CAE) - общая прикладная среда (Common Application Environment);

OPЗMC (DISC) - общепринятые решения заказчиков на основе международных стандартов (Delivering International Solutions to Customers through International Standards);

ОС (OS) - операционная система (Operating System);

OTT (PAS) - общедоступные технические требования (Publicly Available Specifications);

ОУ (CM) - общее управление (Common Management);

ОУБД (ODBC) - открытое управление базами данных (Open Database Connectivity);

ПДЗД (LAPD) - протокол доступа к звену данных (Link Access Protocol D);

ПДС (PPP) - протокол двухточечного соединения (Point-to-Point Protocol);

ПДУФ (FTAM) - передача, доступ и управление файлом (File Transfer, Access and Management);

ПП (АР) - прикладная платформа (Application Platform);

ППИ (API) - прикладной программный интерфейс (Application Program Interface);

ППС (АЕР) - профиль прикладной среды (Application Environment Profile);

ППУС (SNMP) - простой протокол управления сетью (Simple Network Management Protocol);

ППФ (FTP) - протокол передачи файла (File Transfer Protocol);

ППЭП (SMTP) - простой протокол электронной почты (Simple Message Transfer Protocol);

ПС (PS) - прикладная служба (печати) (Print Service);

РАП (ATM) - режим асинхронной передачи (Asynchronous Transfer Mode);

РВС (MAN) - региональная вычислительная сеть (Metropolitan Area Network);

РВСР (DCE) - распределенная вычислительная среда (Distributed Computing Environment);

РГУО (OMG) - рабочая группа по управлению объектами (Object Management Group);

РОТ (DTP) - распределенная обработка транзакций (Distributed Transaction Processing);

PC (WS) - рабочая станция (Workstation);

СИ (NI) - сетевой интерфейс (Network Interface);

СОС (OSE) - среда открытой системы (Open System Environment);

ССФ (NFS) - система сетевых файлов (Network File System);

СТК1 (JTC1) - Совместный технический комитет 1 ИСО/МЭК (Joint Technical Committee 1);

СТП (FUR) - структура требований пользователя (Framework for User Requirements);

СУБД (DBMS) - система управления базой данных (Database Management System);

CУOOBD (OODBMS) - система управления объектно-ориентированной базой данных (Object Oriented Database Management System);

СУРБД (RDBMS) - система управления реляционной базой данных (Relational Database Management System);

ТБ (UUT) - тестируемый блок (модуль) (Unit Under Test);

ТБС (BSR) - требование к бизнес-системе (Business System Requirement);

ТСОП (PSTN) - телефонная сеть общего пользования (Public Switched Telephone Network);

УВП (RPC) - удаленный вызов процедуры (Remote Procedure Call);

УДС (MAC) - управление доступом к среде (Media Access Control);

УЛЗ (LLC) - управление логическим звеном (Logical Link Control);

ФК (FQ) - функциональное качество (Functional Quality);

ФОС (OSF) - фонд открытого программного обеспечения (Open Software Foundation);

ФС (SP) - функциональный стандарт (Standardized Profile);

ЦСИС (ISDN) - цифровая сеть с интеграцией служб (Integrated Services Digital Network);

ЭГ-СОС (EG-OSE) - экспертная группа по среде открытых систем (Expert Group - Open System Environment);

ЭОДФУКТ (ЭДИФАКТ^*)) (EDIFACT) - электронный обмен данными для финансов, управления, коммерции и торговли (Electronic Data Interchange for Finance, Administration, Commerce and Trade);

ЭОД (EDI) - электронный обмен данными (Electronic Data Interchange);

ЯГС (GKS) - ядро графической системы (Graphics Kernel System).

^*) Общепринятые, установившиеся в практике сокращения.

3.3 Обозначения

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

BSD - программные средства, распространяемые лабораторией Беркли (Berkley Software Distribution);

BSI - Британский институт стандартов (British Standards Institute);

CAN - сеть с абонентским доступом для комплекса зданий (Campus Area Network);

C-ISAM - интерфейс языка Си для механизма доступа к индексно-последовательному файлу (The С Language Interface to Index Sequential file Access Mechanism);

e-mail - электронная почта (electronic mail);

FIPS - федеральный стандарт по обработке информации (США), Federal Information Processing Standard);

FTR - федеральные рекомендации по телекоммуникациям (США) (Federal Telecommunications Recommendation);

IAB - Совет по деятельности в Интернете (Internet Activities Board);

IDEF - интегрированное описание и функциональное моделирование (Integrated Definition and Functional Modeling);

IETF - рабочая группа по технологиям в Интернете (Internet Engineering Task Force);

I/F - интерфейс (Interface);

JFIF - формат файла обмена JPEG (JPEG File Interchange Format);

JPEG - объединенная экспертная группа по фотографии (Joint Photographic Experts Group);

MIDI - цифровой интерфейс музыкальных инструментов (Musical Instrument Digital Interfase);

PASC - комитет IEEE по стандартам переносимости приложений (Portable Applications Standards Committee of the IEEE Computer Society);

PHIGS - интерактивные иерархические графические системы для программиста (Programmers Hierarchical Interactive Graphics Systems);

POSC - корпорация открытого программного обеспечения для нефтяной промышленности (Petrotechnical Open Software Corporation);

POSIX - интерфейс операционных систем для вычислительных сред, обеспечивающий переносимость приложений (Portable Operating Systems Interface for Computer Environments);

SGML - стандартный обобщенный язык описания документов (Standard Generalized Markup Language);

SQL - язык структурированных запросов (Structured Query Language);

TCP - протокол управления передачей данных (Transmission Control Protocol);

UDP - протокол дейтаграмм пользователя (User Datagram Protocol);

Win32 - набор руководств фирмы Microsoft по интерфейсам и ППИ системы Windows (The set of Windows interface guidelines and APIs as published by Microsoft);

XA - описание интерфейса СУРБД по каналу передачи данных (X/Open DTP RDBMS interfase definition);

XLIB - системная библиотека X Window (X Window System Library);

ХМ - описание интерфейса X/Open по каналу передачи данных (X/Open DTP Application interfase definition);

XPG - документ стандартов X/Open (X/Open Portability Guide);

XSI - системный интерфейс X/Open (X/Open System Interface);

XTI - транспортный интерфейс X/Open (X/Open Transport Interface);

2D - двумерный (Two Dimensions);

3D - трехмерный (Three Dimensions).

^*) Общепринятые, установившиеся в практике сокращения.

4 Общие положения

4.1 Среда открытых систем (СОС)

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

4.2 Профиль среды открытых систем

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

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

 - инвентаризации принятых подходов к решению задач информатизации и выбора ИТ;

 - помощи при решении вопросов выбора новых продуктов ИТ и их приобретения;

 - управления процессом информатизации организации в целом.

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

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

 - существующие и потенциальные требования («КАК ЕСТЬ» и «КАК ДОЛЖНО БЫТЬ»), установленные профилем СОС, в том числе к стратегии деловой (основной) деятельности, способам практической реализации (функциональной архитектуры) стратегии деловой деятельности, стратегии информатизации, стратегии управления предприятием; конечному пользователю;

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

 - системы, удовлетворяющие требованиям профиля СОС;

 - планы учета (переноса) требований пользователя и необходимых ему услуг;

 - стратегии перехода от одних информационных технологий к другим.

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

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

 - спецификации на закупку оборудования;

 - планы стратегий развития;

 - рекомендуемую последовательность действий;

 - архитектуры технических средств.

4.2.1 Подход POSDC к понятию СОС

Подход POSDC к понятию СОС основывается на выделении в составе информационной системы составных частей или структурных элементов, каждый из которых объединяет в своем составе совокупность объектов, близких по физической природе или родственных по какому-либо признаку, называемую средой. Подход POSIX основан на возможности отделения среды прикладной платформы (application platform entity) от среды прикладных программных средств (application software entity) и внешней среды (external environment) так, как показано на рисунке 1.

Рисунок 1 - Эталонная модель СОС (OSE)

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

Информационная система отвечает требованиям «открытости» в зависимости от следующих аспектов (характеристик) ее реализации:

 - система, на которую не оформлены права собственности (незапатентованная система). Именно такие системы, как правило, имеют в виду, когда утверждают, что «X является открытой системой», где в качестве X могут фигурировать такие системы, средства и компоненты как Ada, POSIX, ANSI С, X Windows и т.д. В этом случае X, теоретически являясь системой, на которую не распространяются права собственности, может и не быть (официально или неофициально) стандартизированной. При этом фактически необходима ее независимая стандартизация без влияния со стороны поставщика (ов);

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

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

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

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

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

4.2.2 Процесс проектирования профиля СОС организации-пользователя

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

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

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

 - этап 3 - определение ТБС (BSR) и ФК (FQ) (например своевременная еженедельная выплата заработной платы);

 - этап 4 - определение требований к информационным службам (например к управлению базами данных и обработке транзакций);

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

 - этап 6 - построение физической модели и выбор базовых стандартов (этот этап часто называют конечным этапом проектирования);

 - этап 7 - анализ физической модели с целью убедиться в выполнении требований ТБС (BSR) и ФК (FQ);

 - этап 8 - окончательная доработка (настройка) физической модели;

 - этап 9 - окончательный выбор базовых стандартов, их вариантов (опций) и других продуктов, в частности программного обеспечения (этот этап часто называют эксплуатационным проектом);

 - этап 10 - определение стоимости жизненного цикла предложенного проектного решения;

 - этап 11 - реализация прототипа физической модели в соответствии с принятым решением.

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

Если физический проект оказывается слишком дорогостоящим для организации, возможен пересмотр ТБС (BSR). Например, при выплате заработной платы организация может изменить технологию платежей (используя электронные платежные документы взамен бумажных или проводя выплаты каждые две недели, а не еженедельно). Такое разделение основного процесса на элементарные процессы (sub-process) часто используют для усовершенствования процесса деловой (основной) деятельности организации. Процедура усовершенствования процесса деловой деятельности организации может быть определена как процесс перехода от состояния «КАК ЕСТЬ» к состоянию «КАК ДОЛЖНО БЫТЬ». Процедуры усовершенствования процесса деловой деятельности организации допускается использовать на начальном этапе выявления требований (этап 2). Профиль СОС формируют на основе композиции результатов, полученных на этапах 8 и 9. В профиле СОС рекомендуется отразить результаты, полученные на этапах 1 - 5. Примерная структура профиля СОС приведена в разделе 7.

4.3 Метод, основанный на понятии жизненного цикла

В настоящих рекомендациях профиль СОС рассматривается с точки зрения его жизненного цикла. Жизненный цикл профиля СОС состоит из следующих этапов (фаз): определения требований (requirement definition), проектирования (design), практической реализации (implementation) и сопровождения (maintenance). На рисунке 2 показана взаимосвязь между стратегией деловой (основной) деятельности организации (в разрезе «сверху вниз» и «снизу вверх») и требованиями к функциональным возможностям системы и проектированию профиля СОС, учитывающим участие пользователей и специалистов по информационным технологиям.

Рисунок 2 - Взаимосвязь между стратегией деловой (основной) деятельности организации и требованиями к функциональным возможностям системы и проектированию профиля СОС

4.3.1 Этап определения требований

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

 - пользователями информационных служб;

 - на основе бизнес-планов организации;

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

 - на основе опыта эксплуатации систем, уже существующих в конкретной организации.

4.3.2 Этап проектирования

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

4.3.3 Этап практической реализации

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

4.3.4 Этап сопровождения

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

4.4 Повторное использование профиля

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

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

4.5 Использование метода построения профилей СОС

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

4.6 Преимущества от использования профилей СОС

Использование профилей СОС дает следующие преимущества:

 - независимость от поставщика;

 - возможность поддержки любого технологического образца;

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

 - обеспечение интеграции и функциональной совместимости;

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

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

5 Профиль СОС в организации-пользователе

5.1 Эталонная модель СОС POSIX

Эталонная модель СОС POSDC (ИСО/МЭК 14252) разработана для обеспечения переносимости приложений между платформами разных производителей. Переносимость приложений расширяет конкурентоспособность применяемых приложений и платформ и обеспечивает автоматическую модернизацию при их изменениях.

Эталонная модель СОС POSDC устанавливает три объекта [прикладные программные средства (application software), прикладную платформу (application platform) и внешнюю среду (external environment)] и два интерфейса между ними, обозначаемых как ППИ (API) и ИВС (EEI).

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

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

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

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

 - службы интерфейса человек-компьютер [ИЧК (HCI)], обеспечивающие переносимость персонала.

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

Рисунок 3 - Эталонная модель СОС POSIX

5.2 Типы профилей

Взаимосвязь между стандартами и различными типами профилей показана на рисунке 4.

Рисунок 4 - Взаимосвязь между стандартами и различными тихими профилей

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

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

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

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

Международный функциональный стандарт (МФС) является международно признанным документом, описывающим один или несколько профилей.

Пример - ИСО/МЭК МФС 11183-1.

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

 - область применения и назначение потребностей или требований пользователя;

 - ссылки на один или несколько базовых стандартов или других профилей;

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

 - решения по «пробелам» в областях действия стандартов или конфликтам между стандартами;

 - требования соответствия профилю.

Профиль СОС должен быть полным, согласованным и однозначно понимаемым.

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

5.3 Профили СОС организации-пользователя

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

 - предприятия в целом (например нефтехимического комбината);

 - области деловой деятельности (ОДД) организации (например технического отдела нефтехимической компании);

 - конкретных технических требований к деловой системе (ТДС) (например автоматизацию учреждения).

Настоящий раздел содержит уточненное описание профилей СОС организации-пользователя. Руководство по разработке профиля СОС организации-пользователя приведено в разделе 6.

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

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

Рисунок 5 - Декомпозиция технологической структуры на составляющие компоненты

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

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

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

Рисунок 6 - Пример технологической структуры организации-пользователя

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

Рисунок 7 - Пример технической вычислительной среды

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

Рисунок 8 - Пример модели (шаблона) технологического компонента

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

Рисунок 9 - Пример модели (шаблона) технологического компонента «Общая рабочая станция»

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

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

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

Рисунок 10 - Пример модели общей службы ИТ (службы отображения)

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

Рисунок 11 - Пример модели используемой службы ИТ (служба отображения в СОС)

6 Процесс разработки профиля СОС организации-пользователя

6.1 Общие положения

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

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

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

6.2 Модель процесса создания профиля СОС организации-пользователя

Общая модель разработки профиля СОС организации-пользователя (рисунок 12) является расширением этапов (фаз) установления требований и проектирования профиля в соответствии с взаимосвязью между стратегией деловой (основной) деятельности организации и требованиями к функциональным возможностям системы и проектированию профиля СОС (рисунок 2).

Рисунок 12 - Общая модель разработки профиля СОС организации-пользователя

Краткое описание этапов разработки профилей СОС в 6.2.1 - 6.2.5. Подробное описание в 6.3 - 6.7.

6.2.1 Область действия

На этом этапе разработки профиля СОС организации-пользователя определяют область его применения, то есть направления деловой деятельности, на которые ориентирован конкретный профиль.

6.2.2 Анализ требований

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

6.2.3 Логический проект

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

6.2.4 Физический проект

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

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

6.2.5 Эксплуатационный проект

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

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

6.3 Определение области действия профиля (этап определения области применения)

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

На этапе определения области применения выявляют:

 - направления деятельности (например отраслей, ведомств), подлежащие учету в профиле;

 - срок реализации профиля, то есть срок окончания создания профиля;

 - деловые и технические стратегии, положения и ограничения;

 - лучшие деловые показатели деятельности конкретной организации;

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

6.4 Анализ требований к документу «Структура требований пользователя»

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

СТП рекомендует определение представительного набора ТБС, определенного посредством процесса декомпозиции служб организации. СТП предусматривает применение метода разработки архитектуры (МРА) [2]. В настоящих рекомендациях приведено описание метода МРА для разработки профилей СОС организации-пользователя, а также другие применяемые методы. Целевое назначение методов разработки архитектуры определяют в три этапа:

1 - установление направлений деятельности (НД);

2 - установление требований к бизнес-системе (ТБС);

3 - выделение служб ИС.

6.4.1 Выделение направлений деятельности (НД)

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

На рисунке 13 приведен пример выделения различных направлений деятельности.

Рисунок 13 - Пример выделения различных направлений деятельности

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

6.4.2 Установление требований к бизнес-системе (ТБС)

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

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

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

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

Рисунок 14 - Пример выделения (декомпозиции) технических направлений деятельности в требования к бизнес-системе

ТБС для области действия профиля должны быть установлены и документально оформлены, исходя из требований их деловых целей и ФК с учетом состава пользователей и качества требуемых служб. Пример каталога ТБС приведен в таблице 1, пример матрицы ТБС/ФК - в таблице 2.

Таблица 1 - Пример каталога ТБС

Таблица 2 - Пример матрицы ТБС/ФК

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

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

ТБС описывают на деловом языке конкретной организации, тем самым обеспечивая взаимную увязку деловых потребностей организации с принимаемыми техническими решениями.

6.4.3 Установление требований к службам ИС

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

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

Функциональные качества, связанные с каждым требованием ТБС, требуют реализации службами ИС, обеспечивающими ТБС.

На рисунке 15 показана взаимосвязь между ТБС и службами ИС.

Рисунок 15 - Взаимосвязь между ТБС и службами ИС и ТБС

Для определения взаимосвязи между требованиями к бизнес-системе и службами ИС используют матрицу. Пример матрицы перекрестных ссылок ТБС/службы ИС приведен в таблице 3.

Таблица 3 - Пример матрицы перекрестных ссылок ТБС/службы ИС

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

Подобные перекрестные ссылки также являются первым этапом отражения деловых требований в технологических (методических) решениях.

6.5 Определение служб ИТ (этап логического проектирования)

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

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

Многоуровневые отношения между службами ИС и ИТ показаны на рисунке 16.

Рисунок 16 - Многоуровневые отношения между службами ИС и ИТ

Рисунок 17 - Выделение (декомпозиция) групп службы ИТ

Эталонная модель СОС POSIX (см. рисунок 3) определяет четыре главные группы служб (услуг) СОС:

1) службу интерфейса человек-компьютер;

2) системную службу;

3) информационную службу;

4) коммуникационную службу.

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

Способ детализации, применяемый в настоящих рекомендациях, предусматривающий три уровня выделения (декомпозиции), показан на рисунке 17.

Группировки модели СОС содержат службы, определенные в эталонной модели СОС POSIX. Группировки профиля СОС организации-пользователя использованы в методе разработки архитектуры (МРА) [2]. Службы ИТ являются самым низким уровнем выделения (декомпозиции) и представляют собой службы, определяемые стандартами и реализуемые в виде продуктов (изделий). Такое выделение (декомпозиция) облегчает построение моделей технологических компонентов, представленных на рисунках 8 и 9.

В таблице 4 представлен пример матрицы перекрестных связей служб ИС и ИТ. В таблице 5 представлен пример матрицы перекрестных связей технологических компонентов и служб ИТ.

Таблица 4 - Пример матрицы перекрестных связей служб ИС и ИТ

Таблица 5 - Пример матрицы перекрестных связей технологических компонентов и служб ИТ

Примеры групп служб ИТ профиля СОС организации-пользователя и охватываемых ими отдельных служб ИТ приведен в таблице 6.

Таблица 6 - Примеры групп служб ИТ профиля СОС организации-пользователя и охватываемых ими отдельных служб ИТ

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

После определения необходимых служб ИТ создают общие модели конкретных служб ИТ как показано на рисунке 10.

6.6 Определение стандартов, технических профилей и внутренних технологий (этап физического проектирования)

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

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

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

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

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

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

 - поиск изделия (реализации, имеющейся в продаже), удовлетворяющего требованиям к службе ИТ;

 - принятие решения, устраняющего отсутствие утвержденного стандарта или спецификации;

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

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

Выбор конкретных стандартов для наполнения логических моделей служб ИТ зависит от:

 - взаимодействия с ранее выбранными стандартами;

 - наличия продуктов (изделий) в продаже;

 - степени соответствия показателям назначения (ФК) (выделенным из ТБС).

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

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

Процесс создания профиля СОС считают завершенным, если наполнены модели служб ИТ, как показано на рисунке 11, и созданы матрицы перекрестных связей, как показано в таблицах 4 и 5. Модели технологических компонентов, полностью определенные в требованиях наполняющих их служб ИТ, и их показатели назначения (ФК) допускается использовать в качестве закупочных спецификаций. Наполненные модели служб ИТ могут быть использованы для разработки и реализации технических заданий, а также в качестве руководства для аттестационного тестирования.

6.7 Выбор продуктов (этап эксплуатационного проектирования)

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

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

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

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

Пример выбора продукции (изделий) приведен на рисунке 18.

Необходимыми исходными данными являются:

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

 - стратегия ИТ организации, разрабатывающей стандарты на изделия конкретной организации и определяющей требования по их сопровождению и эксплуатации другими организациями;

 - физическая модель профиля СОС организации-пользователя;

 - ФК для ТБС - требования к рабочим характеристикам ТБС, использованные для фрагментации профиля, в терминах производительности, числа одновременно работающих пользователей, времени отклика, объемов баз данных, работоспособности, защиты информации и т.д.

Рисунок 18 - Пример выбора продукции (изделий)

Для реализации одного и того же физического технологического компонента могут быть выбраны разные продукты (изделия) в зависимости от ФК служб ИС, которые технологический компонент будет обеспечивать в различных областях, удовлетворяя различным ТБС.

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

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

 - снижать стоимость и сроки процесса заказа;

 - устанавливать долгосрочные отношения с продавцами;

 - стимулировать разработку продуктов (изделий);

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

7 Рекомендуемая структура профиля СОС организации-пользователя

7.1 Рекомендуемая структура

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

Рекомендуемая структура профиля СОС организации-пользователя:

1 Назначение данного профиля СОС организации-пользователя.

2 Специфика предприятия.

3 Детализированный профиль СОС организации-пользователя:

а) область применения профиля;

б) анализ требований;

в) логический проект;

г) физический проект.

4 Заключение и выводы.

7.1.1 Назначение конкретного профиля СОС организации-пользователя

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

7.1.2 Специфика предприятия в профиле СОС организации-пользователя

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

7.1.3 Детализированный профиль СОС организации-пользователя

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

7.1.3.1 Область применения профиля

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

7.1.3.2 Анализ требований

Настоящий подпункт должен документально представлять в наиболее наглядной форме направления деятельности (НД), выделяемые в следующие области применения профиля:

 - принятого и утвержденного каталога ТБС-документов, включая ФК для каждого ТБС;

 - выбранных служб ИС, документально оформленных в виде каталога служб ИС;

 - матрицы перекрестных связей (ссылок) ТБС/службы ИС.

7.1.3.3 Логический проект

Настоящий подпункт должен документировать логический проект профиля СОС организации-пользователя с учетом:

 - выбранных служб ИТ;

 - матрицы перекрестных связей служб ИС и ИТ;

 - логических моделей технологических компонентов;

 - логических моделей служб ИТ;

 - компьютерной среды для каждой из областей деловой деятельности;

 - технологической структуры - общей диаграммы области применения в пределах развертываемых технологических компонентов;

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

7.1.3.4 Физический проект

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

8 Вопросы, связанные с профилем СОС организации-пользователя

8.1 Аттестационное тестирование

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

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

 - тестирование конкретных заявок о соответствии базовым стандартам СОС или спецификациям (некоторые или все заявки могли быть проверены в ранее проведенных испытаниях);

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

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

Рисунок 19 - Определение соответствия технической реализации на основе эталонной реализации стандарта

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

8.2 Вопросы реализации

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

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

8.3 Планирование внедрения

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

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

8.4 Использование общедоступных технических требований

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

9 Преимущества профилей СОС организации-пользователя

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

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

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

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

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

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

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

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

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

Рисунок 20 - Обобщенная схема разработки профиля СОС организации-пользователя

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

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

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

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

ПРИЛОЖЕНИЕ А

(справочное)

Библиография

[1] IEEE Std 1003.23-98 Стандарт института инженеров по электротехнике и электронике. Руководство по проектированию профилей среды открытой системы организации-пользователя

[2] CAP Gemini Sogeti, Architecture Development Method, April 7, 1995