Руководство по окружению открытых систем

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

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

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

По существу сформировались не только концептуальные и методологические основы открытых систем, но и достаточно развитый аппарат конструирования и сертифицирования новых открытых технологий в пространстве базовых стандартизованных решений. Таким образом сегодня можно говорить о формировании новой научной дисциплины, безусловно базовой для информатики, но не получившей еще общепризнанного названия. Предлагаемыми названиями являются: «IT Fundamentals», «The Foundations of IT», «Analysis of IT», «IT-Sience», «Itology», «Анализ ИТ» или «Итология».

Базовые понятия концепции открытых систем

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

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

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

Базовый стандарт или базовые спецификации (формальный стандарт или стандарт de-ure). Международный стандарт, принятый ISO или Рекомендация организации ITU-T (до 1993 г. — CCITT) — международного союза по телекоммуникации.

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

ИТ-система (IT system). Совокупность ресурсов информационных технологий, предоставляющая сервисы на одном или более интерфейсов.

OSE (Open Systems Environment — Окружение открытых систем). Полный набор интерфейсов, услуг, форматов, а также пользовательских аспектов, обеспечивающих интероперабельность и/или переносимость приложений, и данных в рамках соответствующих спецификаций базовых стандартов и профилей ИТ. Важным и почти обязательным свойством открытости является свойство масштабируемости ИТ. В эталонной модели прикладного пользовательского интерфейса (API) [4] под открытой системой фактически понимается система, реализующая OSE — окружение, удовлетворяющее стандартам.

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

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

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

PAS (Publicly Available Specifications — Общедоступные спецификации). По существу это понятие охватывает опубликованные стандарты de-facto, например, промышленные стандарты. Близким по смыслу понятию PAS является понятие открытых спецификаций, определенное в эталонной модели API [4]. Примерами PAS могут служить спецификации IEEE POSIX и X/Open XPG4, разработанные с целью обеспечения переносимости приложений, а также спецификации IETF для TCP/IP.

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

ISP (International Standardized Profile — Международный стандартизованный профиль). Согласованный на международном уровне официальный документ, описывающий один или несколько профилей. В эталонной модели API используется близкое понятие стандартизованного профиля.

OSE-профиль. Профиль, который специфицирует все поведение ИТ-системы или часть ее поведения на одном или большем числе интерфейсов OSE.

OSI-профиль. Конкретный профиль, составленный из базовых спецификаций, соответствующих модели OSI [5], возможно дополненных базовыми стандартами и/или профилями для представления данных обмена и их форматов — так называемыми F-профилями.

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

Таксономия (Taxonomy) — классификационная схема, применяемая для однозначной идентификации профилей или наборов профилей.

Структура методологического базиса

МНОГОУРОВНЕВАЯ МОДЕЛЬ

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

Рис. 1. Структура знания итологии.

1) Концептуальный уровень или уровень метазнаний — состоит из архитектурных спецификаций, называемых эталонными моделями (Reference Models). Архитектурные спецификации предназначены для структуризации спецификаций функций, определяющих семантику конкретных областей ИТ.

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

3) Предметные или локальные профили ИТ (например, OSI-профили, API-профили), т.е. профили, разрабатываемые на основе использования базовых спецификаций, относящихся к предметной области, описанной одной эталонной моделью (возможно вместе с профилями форматов данных, т.е. F-профилями).

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

5) Полные OSE-профили открытых платформ и систем — спецификации, предназначенные для описания поведения ИТ-систем на всех их интерфейсах.

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

7) Стратегические профили (например, GOSEP — Government’s Open System Environ-ment Profole), т.е. профили, рассматриваемые в данном случае не как спецификации одной технологии, а как наборы стандартов, определяющих техническую политику в области телекоммуникации и открытых технологий крупной организации или даже государства.

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

АРХИТЕКТУРНЫЕ СПЕЦИФИКАЦИИ

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

• Базовая эталонная модель взаимосвязи открытых систем (Basic Reference Model for Open Sysnems Interconnection — RM-OSI) [5].
• Руководство по окружению открытых систем POSIX (Portable Operating System Interface for Computer Environments — RM API) [6].
• Эталонная модель для открытой распределенной обработки (Reference Model for Open Distributed Processing — RM-ODP) [7].
• Эталонная модель управления данными (Reference Model for Data Management — RM DF) [8].
• Эталонная модель машинной графики (Reference Model of Computer Graphics — RM CG) [9].
• Эталонная модель текстовых и офисных систем (ISO/IEC TROTSM-1) [10], а также общая (general) модель распределенных офисных приложений [11].

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

• Конформность (соответствие, подобие) и методы тестирования конформности, называемые также методами аттестационного тестирования;
• основы общей безопасности (generic security frameworks);
• качество OSI-сервиса (Quality of Service for OSI).

УРОВЕНЬ БАЗОВЫХ СПЕЦИФИКАЦИЙ

Базовые спецификации являются основными строительными блоками, из которых конструируются конкретные открытые технологии. Хотя PAS, в соответствии с данным выше определением, охватывают стандарты de-facto, которые не являются международными стандартами, сейчас интенсивно осуществляется процесс принятия наиболее распространенных и сопровождаемых PAS в качестве международных стандартов (по специально разработанной ISO быстрой процедуре баллотирования PAS), что открывает возможность использования PAS в качестве элементов стандартизованных профилей ИТ. Системный подход к проектированию профилей [12] опирается на классификацию базовых спецификаций и PAS, в основе которой используется по существу ортогональный набор эталонных моделей. В частности, возможна следующая классификация базовых спецификаций и PAS.

a) Базовые функции ОС: определяются стандартами по окружению открытых систем POSIX (Portable Operaring System Interface for Computer Environments) [13].

б) Функции управления базами данных: язык баз данных SQL (Structured Query Language) [14]; информационно-справочная система IRD (Information Resource Dictionary System) [15]; протокол распределенных операций RDA (Remote Data base Access) [16]; PAS Microsoft на открытый прикладной интерфейс доступа к базам данных ODBC API [17].

в) Функции пользовательского интерфейса, которые включают следующие ИТ: MOTIF из OSF для графического пользовательского интерфейса (GUI) [18] и стандарт OPEN LOOK [19]; X Window вместе с GUI и телекоммуникациями [20]; стандарты для виртуального терминала (Virtual Terminal — VT) [21], включая процедуры работы VT в символьном режиме через TCP/IP; стандарты машинной графики GKS (Graphical Kernel System) [22], GKS-3D (Graphical Kernel System — 3 Dimentional) [23], PHIGS (Programmers Hierarchical Interactive Graphics System) [24], а также CGI (Computer Graphics Interface) [25].

г) Функции взаимосвязи открытых систем, включающие: спецификации сервиса и протоколов, разработанные в соответствии с моделью OSI (рекомендации серии X.200) [26]; стандарты для локальных сетей (IEEE 802) [27]; спецификации сети Internet [28, 29, 30].

д) Функции распределенной обработки, включая следующие базовые спецификации OSI: вызов удаленной процедуры RPC (Remote Procedure Call) [31], фиксация, параллельность и восстановление CCR (Commitment, Concurrency and Recovery) [32]; протокол надежной передачи (RT) [33]; обработка распределенной транзакции DTP (Distributed Transaction Processing) [34]; управление файлами, доступ к файлам и передача файлов FTAM (File Transfer, Access and Management) [35]; управление открытыми системами (OSI Management) [36]; API для доступа к сервису Object Request Broker (ORB) в архитектуре CORBA и API, определяющий базовые возможности такого сервиса (Commom Object Services — COS 1) [37], а также язык спецификации интерфейсов объектов IDL (Interface Definition Language) [37] и его проекции на объектно-ориентированные языки.

е) Распределенные приложения: спецификации специальных сервисных элементов прикладного уровня модели OSI, стандартов Internet, OMG, X/Open. Как, например: система обработки сообщений MHS (Message Handling System — X.400) [38], служба справочника (The Directory — X.500) [39]; спецификации распределенных приложений с архитектурой клиент-сервер [11] и распределенных объектных приложений [37].

ж) Структуры данных и документов, форматы данных: средства языка ASN.1 (Abstract Syntax Notation One) [40, 41], предназначенного для спецификации прикладных структур данных — абстрактного синтаксиса прикладных объектов; форматы метафайла для представления и передачи графической информации CGM (Computer Graphics Metafile) [42]; спецификация сообщений и электронных данных для электронного обмена в управлении, коммерции и транспорте EDIFACT (Electronic Data Interchange for Administration, Commence and Trade) [43]; спецификации документов: спецификации структур учрежденческих документов ODA (Open Document Architecture) [44]; спецификации структур документов для производства, например: SGML (Standard Generalized Markup Language) [45, 46]; языки описания документов гипермедиа и мультимедиа, например: HyTime [47], SMDL (Standard Music Description Language) [48], SMSL (Standard Multimedia/Hypermedia Scripting Language) [49], SPDS (Standard Page Description Language) [50], DSSSL (Document Style Semantics and Specification Language) [51], HTML (HyperText Markup Language) [45]; спецификация форматов графических данных, например: форматов JPEG [52], JBIG [53] и MPEG [54].

з) спецификации инструментальных окружений (в частности, языков реализации и их библиотек) и CASE-окружений (как, например, [55]). Анализ базовых спецификаций ИТ показывает, что современная методологическая база открытых систем представляет собой сложную систему концептуальных, структурных, функциональных, поведенческих и лингвистических моделей, взаимосвязанных между собой, а также вспомогательных процедур и средств. При этом следует отметить динамичность развития всей этой системы, поддерживаемого целенаправленной деятельностью развитой инфраструктуры специализированных международных институтов.

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

***

В заключении хотелось бы выразить благодарность коллегам из специальной рабочей группы по функциональной стандартизации (Special Group on Functional Standardization — SGFS of JEC 1), и прежде всего ее председателю Dr. Willem Wakker, за предоставленную возможность участия в деятельности группы и возможность использования ее рабочих материалов.

Литература

1] ISO/IEC TR 10000-1:1995 (final text, June 1995), Information technology — Framework and taxonomy of International Standardized Profiles — Part 1:General Principles and Documentation Framework.

2] ISO/IEC TR 10000-2:1995 (final text, June 1995), Information technology — Framework and taxonomy of International Standardized Profiles — Part 2: Principles and Taxonomy for OSI Profiles.

3] ISO/IEC TR 10000-3:1995 (final text, June 1995), Information technology — Principles and taxonomy of International Standardized Profiles — Part 3: Principles and Taxonomy for Open System Environment Profiles.

4] P1003.0 Draft 18. STANDARDS PROJECT. Draft Guide to the POSIX Open System Environment. IEEE. February 1995.

5] ISO 7498:1984, Information processing systems — Open Systems Interconnection- Basic Reference Model [ITU-T Rec. X.200 (1994)].

6] ISO/IEC DTR 14252, Portable Operaring System Interface for Computer Environments — POSIX. (IEEE, P1003.0 Draft 18, Draft Guide to the POSIX Open System Environment, February 1995).

7] ITU-T Rec. 902|ISO/IEC 10746-2:1995, Reference Model for Open Distributed Processing.

8] DIS 9075:1992, Information technology — Reference Model for Data Management.

9] ISO/IEC 11072:1992, Information Technology — Computer Graphics — Computer Graphics Reference Model.

10] ISO/IEC TRTOSM-1, Information technology — Text and office systems reference model — Part 1. Basic reference model.

11] ISO/IEC 10031/1:1991, Information technology — Text communication — Distributed-office-applications model — Part 1. General model.

12] Draft ETGnn Development and Use of OSE Profiles. EMOS/EG-OSE/95/10, 1995.

13] ISO/IEC 9945/1:1990, (IEEE Std 1003.1 — 1990), Information technology — Portable Operating System Interface (POSIX) — Part 1:System Application Program Interface (API) [C Language].

14] ISO/IEC 9075:1992 (ANSI X3.135-1992), Information technology — Database — Database Language — SQL (Structured Query Language).

15] ISO/IEC 10027:1990, Information technology — Information Resource Dictionary System (IRDS) framework.

16] ISO/IEC 9579:1993, Information technology — Open Systems Interconnection — Remote Database Access (RDA).

[17] Роберт Сигнор, Михаэль О. Стегман. Использование ODBC для доступа к базам данных: Пер. с англ. — М. БИНОМ; НАУЧНАЯ КНИГА. — 386с.: ил.

[18] OSF/MOTIF, Open Software Foundation, MOTIF Release 1.2.

[19] Open Look. Draphical User Interface. Application Style Guidelines. Sun Microsystems, Inc. 1991.

[20] FIBS PUB 158-2: User Interface Component of Application Portability Profile (MIT X Window System) — X library API specification. (X Window System, Version 11, Realease 5, MIT X Consortium).

[21] ISO 9040:1990, Information technology — Open Systems Interconnection — Virtual terminal basic class service.

[22] ISO/IEC 7942:85, Information processing systems — Computer graphics — Graphical Kernel System (GKS) functional description.

[23] ISO/IEC 8805:88, Information processing systems — Computer graphics — Graphical Kernel System for three dementions (GKS-3D) functional description.

[24] ISO/IEC 9592/1:89, Information processing systems — Computer graphics — Programmer’s Hierarchical Interactive Graphics System (PHIGS) — Part 1. Functional description.

[25] ISO/IEC 9636:91, Information technology — Computer graphics — Interfacing techniques for dialogues with graphical devices (CGI) — Functional specification — Part 1 — 6.

[26] Зайцев С.С., М.И. Кравцунов, С.В. Ротанов СПРАВОЧНИК. Сервис открытых информационно-вычислительных сетей. М. Радио и связь, 1990. [ITU-T (CCITT), Rec. X.200-X.219, 1988].

[27] ISO/JEC 8802:1990 (IEEE Std 802-1990), Information processing systems — Local area networks.

[28] Transmission Control Protocol (TCP) — RFC 793.

[29] User Datagram Protocol (UDP) — RFC 768.

[30] Internet Protocol (IP) — RFC 791.

[31] ISO/IEC 10148, Information processing systems — Open Systems Interconnection — Basic Remote Procedure Call (RPC) using OSI Remote Operations.

[32] ISO/IEC 9804:1994, Information processing systems — Open Systems Interconnection — Service definition for the Commitment, Concurrency and Recovery service element.

[33] ISO/IEC 9075:1992, Information processing systems — Text communication — Reliable Transfer — Part 1. Model and service definition.

[34] ISO/IEC 10026:1992, Information technology — Open Systems Interconnection — Distributed Transaction Processing — Part 1: OSI TP Model.

[35] ISO 8571/1:1988, Information processing systems — Open Systems Interconnection — File transfer, access and management — Part 1. General introduction.

[36] ISO 10040:1992, Information technology — Open Systems Interconnection — System management overview.

[37] OMG Document Number 91.12.1. The Common Object Request Broker: Architecture and Specification. R.1.1.

[38] ISO/IEC 10021/1:1990, Information technology — Text communication — Message-Oriented Text Interchange System (MOTIS) — Part 1: System and service overview. [ITU-T Rec. X.400, Message handling system and service overview].

[39] ISO 9594:1990, Information technology — Open Systems Interconnection — The Directory — Part 1: Overview of concepts, models and services. [Rec. X.500].

[40] ISO 8824:1990, Information processing systems — Open Systems Interconnection — Specification of Abstract Syntax Notation One (ASN.1).

[41] ISO 8825:1990, Information processing systems — Open Systems Interconnection — Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1).

[42] ISO/IEC 8632/1:87, Information technology — Computer graphics — Metafile for the storage and transfer of picture description information — Part 1. Functional description.

[43] ISO 9735:1988, Electronic Data Interchange for Administration, Commerce and Transport (EDIFACT) — Application level syntax rules (Amended and reprinted 1990).

[44] ISO/IEC 8613/1:1994, Information technology — Open Document Architecture (ODA) and Interchange Format — Introduction and general principles. [ITU-T Rec. T.411(1993)].

[45] ISO/IEC 8879:1986, Information processing — Text and office systems — Standard Generalized Marking Language (SGML).

[46] ISO/IEC TR9573:1988, Information processing — SGML support facilities — Techniques for using SGML.

[47] ISO/IEC 10744:1992, Information technology — Hypermedia/time-based structuring language (HyTime).

[48] ISO/IEC 10743:1992, Standard Music Description Language (SMDL).

[49] ISO/SC1/WG8:1993, Standard Multimedia/Hypermedia Scripting Language (SMSL).

[50] ISO/IEC 10180:1994:…, Information technology — Text communication — Standard Page Description Language (SPDL).

[51] ISO/IEC 10179:…, Information technology — Text and office systems — Document Style Semantics and Specification Language (DSSSL).

[52] ISO DIS 11544, Joint Bi-level Image Expert Group (JBIG).

[53] ISO DIS 10918-1,2, Joint Photographic Expert Group (JPEG).

[54] ISO DIS 11172-1,2, Moving Pictures Expert Group (MPEG).

[55] ISO/IEC DIS 13719, ECMA Portable Common Tool Environment.

Владимир Сухомлин (www.sukhomlin.ru) — профессор факультета ВМиК МГУ им. Ломоносова (Москва).

Р 50.1.041-2002

РЕКОМЕНДАЦИИ ПО СТАНДАРТИЗАЦИИ

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

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

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

Предисловие

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

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

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

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

СОДЕРЖАНИЕ

Введение

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

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

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

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

Р 50.1.041-2002

РЕКОМЕНДАЦИИ ПО СТАНДАРТИЗАЦИИ

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

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

Information technologies. Guide for
developing the User Organization Open System Environment (OSE) profiles

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

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

Процесс проектирования профиля СОС, применимый при
реализации любого подхода к процедуре проектирования, в том числе основанного
на применении лицензионных (запатентованных) продуктов и решений, описан в
разделе 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 представлен пример матрицы перекрестных связей
технологических компонентов и служб ИТ.

Примеры групп служб ИТ профиля СОС
организации-пользователя и охватываемых ими отдельных служб ИТ приведен в
таблице 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

Открытые системы как основа для построения Умного города

Ключевые слова: умный город, открытые системы, open source system, smart city, качество жизни, умные технологии.

Цель: определить понимание открытых систем как основы для проектирования Умного города, а также ознакомить с принципами концепции открытых систем.

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

Введение 

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

Понятие «Умного города»

Умный город — инновационный город, который внедряет комплекс технических решений и организационных мероприятий, направленных на достижение максимально возможного в настоящее время качества управления ресурсами и предоставления услуг, в целях создания устойчивых благоприятных условий проживания и пребывания, деловой активности нынешнего и будущих поколений [1].

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

На практике выделяют несколько основных компонентов «Умного города»: 

1. Энергетика: автоматизированная интеллектуальная энергосеть и гибкая распределительная система; интеллектуальная система учета и регулирование спроса; внедрение возобновляемых видов энергии; энергоэффективные здания и сооружения.

2. Водоснабжение: автоматизированные водозабор, водораспределение, водоотведение и обнаружение утечек; интеллектуальная система учета и регулирование спроса.

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

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

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

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

7. Жители: пользователи объектов инфраструктуры и информационных услуг; поставщики информации в режиме «обратной связи»

Чтобы понять, как работает система “Умного города”, необходимо детализировать ознакомиться с ее технической частью, с подсистемами. Таким образом, спустившись на технический уровень, обращаемся к концепциям открытых систем, на основе которых существует “Умный город”.

Концепция открытых систем 

«Открытая система — это система, которая состоит из компонентов, взаимодействующих друг с другом через стандартные интерфейсы». Это определение, данное одним из авторов упомянутого руководства Жаном-Мишелем Корну, подчеркивает системный аспект (структуру открытой системы). Данное руководство было издано Французской ассоциацией пользователей UNIX (АFUU) в 1992 году [2].

«Исчерпывающий и согласованный набор международных стандартов информационных технологий и профилей функциональных стандартов, которые описывают  интерфейсы, службы и поддерживающие форматы, чтобы обеспечить интероперабельность и мобильность приложений, данных и персонала». Это определение, данное специалистами IЕЕЕ, подчеркивает аспект среды, которую предоставляет открытая система для ее использования (внешнее описание открытой системы) [3].

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

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

• расширяемость (масштабируемость),

• мобильность (переносимость),

• интероперабельность (способность к взаимодействию с другими системами),

• дружественность к пользователю, в т.ч. — легкая управляемость.

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

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

C 2012 года произошел ряд качественных скачков в технологиях — были разработаны новые интерфейсы связи и протоколы передачи данных. Одним из наиболее известных интерфейсов связи является LoRa.

Технология LoRa — объединяет в себе метод модуляцииLoRа в беспроводных сетях LPWAN и открытый протокол LoRaWan, обеспечивает межмашинное взаимодействие (M2M) на расстояния до 15 км при минимальном потреблении электроэнергии, обеспечивающем несколько лет автономной работы на одном аккумуляторе АА. Диапазон применений данной технологии огромен: от домашней автоматизации и интернета вещей (IoT) до промышленности и Умных Городов.

Также рассмотрим протокол беспроводной сети IEEE 802.11ah, названный Wi-Fi HaLow. Этот протокол работает на не требующей лицензирования частоте 900 МГц, для обеспечения расширенного диапазона Wi-Fi сетей, по сравнению с обычными сетями Wi-Fi, работающими в диапазонах 2.4 ГГц и 5 ГГц. Его низкое энергопотребление является преимуществом, позволяющим создавать большие группы станций или датчиков, которые взаимодействуют чтобы распространять сигналы, поддерживая концепцию Интернета вещей (Internet of Things, IoT). Низкое энергопотребление протокола конкурирует с Bluetooth и имеет дополнительное преимущество — более высокие скорости передачи данных и более широкий диапазон покрытия.

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

В связи с этим нужно уточнить представление об архитектуре систем и средств, как внешнем их описании с точки зрения того, кто ими пользуется. Архитектура открытой системы, таким образом, оказывается иерархическим описанием ее внешнего облика и каждого компонента: пользовательского интерфейса, среды проектирования, систем и инструментальных средств, архитектуры ЭВМ, интерфейсов оборудования.

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

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

Помимо приведенных выше в качестве примера интерфейсов системы хочется привести два класса интерфейсов: интерфейс прикладной программы и интерфейс внешней среды: 

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

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

Роль открытых систем в Умном городе

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

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

К примеру, опыт создания программно-аппаратных комплексов, обобщавшийся в последние годы, привел к необходимости разработки концепции и комплекса стандартов, обеспечивающих эффективную по трудоемкости переносимость прикладных программ между различными аппаратными и операционными платформами. Ядром стала группа стандартов, созданная специалистами США под эгидой IEEE под общим названием – Интерфейсы переносимых операционных систем (Portable operating system interface – POSIX). Проблему переноса программ сосредоточили на унификации интерфейсов операционных систем ЭВМ с различными прикладными программами, а также с окружающей средой. Эти стандарты не ориентированы на определенную конкретную архитектуру ЭВМ, однако предполагают использование современной операционной среды и прежде всего UNIX, как стандарта де-факто, а также международных стандартов на языки программирования и стандартов верхних уровней взаимосвязи открытых систем. В совокупности они образуют нормативную базу открытых компьютерных систем – OCS, обеспечивающих программных устройств.

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

1. IEEE 1003.0 – Руководство по POSIX окружению открытых систем. Набор POSIX стандартов.

2. ISO 09945-1:1990 (IEEE 1003.1) –Информационная технология. Интерфейсы переносимых операционных систем.

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

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

Примеры

В последние годы возникло множество вариантов беспроводной передачи данных – давно знакомые GSM, GPRS, 3G, Wi-Fi, так и новые технологии, такие как LoRaWAN. Технология LoRaWAN в последнее время все активнее внедряется в приборный учет, освещение, управление энергосистемами.

Вкратце введем в архитектуру технологии LoRAWAN и детализируем ее описание:

• Сенсоры LoRaWAN могут передавать информацию на дистанции 15 км — в малых городах и более 2 км — в плотно застроенных городах, обеспечивая скорость обмена данными от 300 бит/сек до 100 кбит/сек.

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

• Ключи шифрования AES128 делают фактически невозможными взлом и прослушивание.

• Сеть LoRaWAN имеет топологию звезда из звёзд и включает в себя конечные узлы, шлюзы, сетевой сервер и сервер приложений.

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

• Шлюз LoRa — базовые станции, принимающее данные от конечных устройств с помощью радиоканала и передающее их в транзитную сеть, в качестве которых могут выступать Ethernet, сотовые сети.

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

• LoRaWAN позволяет строить распределенные беспроводные сети с большим числом конечных узлов. Один LoRa-шлюз допускает обслуживание до пяти тысяч конечных устройств, что достигается за счёт топологии сети, адаптивной скорости передачи данных, временным разделением, частотным разделением каналов.

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

В России данную технологию поставляет ряд крупнейших компаний. Например, ООО «Лартех» является одним из производителей радиомодулей и оператором сети LoRaWAN. Лартех» с самого начала производил оборудование в полном соответствии со спецификацией разрабатываемого стандарта, поэтому даже ранее поставленное заказчикам оборудование уже работает в рамках национального стандарта LoRaWAN. Представленные проекты данной компании акцентированы на системе учета энергоресурсов. Это и теплосчетчики с радиомодулями, электросчетчики, счетчики показателей воды с считывателем.[4]

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

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

Другими примерами также могут служить запуск пилотного проекта Умный город в Подмосковье от компании МТС в сентябре 2019. Проект реализуется в рамках программы губернатора Московской области Андрея Воробьева «Безопасный район» и включает три направления: экомониторинг, оптимизацию вывоза бытовых отходов и установку в ряде жилых домов интерактивных инфопанелей.

Датчики экомониторинга призваны заменить находящийся на реконструкции сайт Мосэкомониторинга и контролировать уровень выбросов с полигона «Кучино». В рамках пилотного проекта МТС установила специальные датчики в районе «Новокосино-2», в районе железнодорожной станции «Реутов» и метро «Новокосино». Система в режиме реального времени отслеживает текущую экологическую обстановку в городе: температуру и влажность воздуха, выбросы углекислого газа и концентрацию меркаптанов и формальдегидов – токсичных веществ, которые не только являются причиной неприятного запаха, но и в высоких концентрациях вредны для здоровья человека. В случае превышения значений предельно допустимой концентрации веществ в воздухе, система автоматически проинформирует городские надзорные органы. Мониторинг позволяет следить за состоянием воздуха в городе, фиксировать частоту и масштаб выбросов вредных веществ.

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

МТС установила в контейнеры пыле- и влагозащищенные ударопрочные датчики, которые фиксируют уровень его наполняемости, а также отслеживают наличие в воздухе определенных газов, что позволит оперативно отреагировать, например, на возгорание мусора. Датчики подходят для разных типов контейнеров: как для смешанного, так и раздельного сбора мусора. При помощи сети NB-IoT данные о состоянии контейнера отправляются в онлайн-систему планирования и контроля, которая прогнозирует скорость их наполнения. На основании прогноза система рассчитывает оптимальный маршрут сбора и вывоза отходов.

На текущий момент представленный проект продолжает развиваться и масштабируется на другие города Московской области. В 2021-2022 гг. запланировано строительство в 20 городах, в 2023-м — еще в семи городах. При выборе городов также учитывалось наличие массовой застройки и число зданий высокой этажности, близость к МКАД и степень экономической активности.

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

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

Преимущества использования открытых систем в «Умном городе»

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

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

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

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

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

Заключение 

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

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

Список используемых источников

1. ПНСТ 439-2020 (ИСО/МЭК 30182:2017) Информационные технологии (ИТ). Умный город. Совместимость данных [Электронный ресурс] /. — Электрон. журн. — Режим доступа: http://docs.cntd.ru/document/1200174806

2. Открытые системы, процессы стандартизации и профили стандартов [Электронный ресурс] /. — Электрон. журн. — Режим доступа: http://citforum.ru/database/articles/art19.shtml

3. Открытая информационная система [Электронный ресурс] /. — Электрон. журн. — Режим доступа: https://ru.wikipedia.org/wiki/Открытаяинформационнаясистема(информатика)

4. Статус национального стандарта России [Электронный ресурс] /. — Электрон. журн. — Режим доступа: https://lar.tech/news/news-084

Дата актуализации: 01.01.2021

Р 50.1.041-2002

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

Обозначение:	Р 50.1.041-2002
Обозначение англ:	R 50.1.041-2002
Статус:	Действует
Название рус.:	Информационные технологии. Руководство по проектированию профилей среды открытой системы (СОС) организации-пользователя
Название англ.:	Information technologies. Guide for developing the user organization open system environment (OSE) profiles
Дата добавления в базу:	01.09.2013
Дата актуализации:	01.01.2021
Дата введения:	01.01.2004
Область применения:	Рекомендации предназначены для описания процесса проектирования профилей среды открытых систем (СОС) организации-пользователя (профилей СОС). Рекомендации содержат описание основных принципов оформления требований пользователя и сведения об информационных технологиях (ИТ) и службах (услугах), которые могут обеспечить выполнение требований пользователей, а также информацию о порядке выбора стандартов, спецификаций и рекомендаций, которые должны обеспечивать поддержку ИТ и их служб. В рекомендациях также рассматривается необходимость подготовки плана формирования больших систем, включая описание таких мероприятий, как, например, аттестационное тестирование, сопровождающих применение профилей.
Оглавление:	1 Область применения 2 Нормативные ссылки 3 Определения, сокращения и обозначения    3.1 Определения    3.2 Сокращения    3.3 Обозначения 4 Общие положения    4.1 Среда открытых систем (СОС)    4.2 Профиль среды открытых систем    4.3 Метод, основанный на понятии жизненного цикла    4.4 Повторное использование профиля    4.5 Использование метода построения профилей СОС    4.6 Преимущества от использования профилей СОС 5 Профиль СОС в организации-пользователе    5.1 Эталонная модель СОС POSIX    5.2 Типы профилей    5.3 Профили СОС организации-пользователя 6 Процесс разработки профиля СОС организации-пользователя    6.1 Общие положения    6.2 Модель процесса создания профиля СОС организации-пользователя    6.3 Определение области действия профиля (этап определения области применения)    6.4 Анализ требований к документу «Структура требований пользователя»    6.5 Определение служб ИТ (этап логического проектирования)    6.6 Определение стандартов, технических профилей и внутренних технологий (этап физического проектирования)    6.7 Выбор продуктов (этап эксплуатационного проектирования) 7 Рекомендуемая структура профиля СОС организации-пользователя    7.1 Рекомендуемая структура 8 Вопросы, связанные с профилем СОС организации-пользователя    8.1 Аттестационное тестирование    8.2 Вопросы реализации    8.3 Планирование внедрения    8.4 Использование общедоступных технических требований 9 Преимущества профилей СОС организации-пользователя Приложение А Библиография
Разработан:	ВНИИстандарт Госстандарта России ТК 22 Информационные технологии ИРЭ РАН (институт радиотехники и электроники российской академии наук)
Утверждён:	14.11.2002 Госстандарт России (Russian Federation Gosstandart 415-ст)
Издан:	ИПК Издательство стандартов (2003 г. )
Расположен в:	Техническая документация Экология ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ. МАШИНЫ КОНТОРСКИЕ Взаимосвязь открытых систем Многоуровневые прикладные системы