Во-первых, она должна непрерывно корректироваться по мере развития, с одной стороны, самих программных технологий, а с другой стороны – общего видения задач электронного государства.
Во-вторых, положенный в основу архитектуры принцип функциональной стандартизации (профилирования) реализован в текущей версии АПО в достаточно общем виде. Многие идеи и концепции использованных при проектировании ЭФМ были упрощены или исключены из рассмотрения в целях облегчения понимания документа конечными пользователями, и, следовательно, более успешного внедрения АПО на начальных этапах.
Как следствие, в некоторых случаях вместо строгого системного подхода использовались эмпирические построения или метод аналогий (т. е. заимствовались «обкатанные» идеи из опыта других стран) Собственно говоря, и само упрощение модели продиктовано анализом международного опыта: в большинстве успешных проектов создания архитектурно-технологических концепций электронного государства зачастую выбираются более простые, практически направленные решения в противовес теоретически выдержанным, но сложным в применении.
В то же время разработчики считают недопустимым полное игнорирование передовых наработок, накопленных мировым научным сообществом в области функциональной стандартизации. Проектирование архитектурных моделей по принципу ad hoc («по мере возникновения проблем») может привести к нарастающему хаосу спецификаций и трудно разрешимым противоречиям в подходах. В связи с этим даже при использовании эмпирических локальных решений следует руководствоваться общим системным видением задач АПО.
В данном разделе настоящей пояснительной записки рассмотрена некоторая будущая целевая модель, основанная на анализе наиболее прогрессивных разработок международных стандартизующих организаций, в первую очередь Совета по Стандартизации в области Информационных и Коммуникационных Технологий (ICTSB - Information and Communications Technologies Standards Board), который реализует наиболее комплексный подход к проблематике данной области и объединяет опыт многих международных и национальных стандартизирующих организаций. Предложенная модель развития может быть реализована по мере возрастания готовности российского электронного государства. Однако уже при создании текущей версии АПО разработчик стремился придерживаться принципа потенциальной совместимости «снизу вверх» с будущей моделью.
Описанная ниже модель не является неким законченным и однозначным решением. Описание ее не является исчерпывающим и должно детализироваться и разъясняться по мере разработки. Использованная в разделе терминологическая система значительно шире, чем предложена в Глоссарии (Приложение 1), и при этом требует дальнейшего уточнения и совершенствования. В целом данный раздел пояснительной записки следует рассматривать исключительно как дискуссионную основу для выработки плана будущих работ по совершенствованию АПО.
4.15.1 Базовая модель АПО
АПО должна стать моделью доступа пользователей к прикладным и коммуникационным сервисам ЭГ. В качестве основного системообразующего элемента АПО при этом используется сетевая инфраструктура, образующая бесшовное объединение в единую всеобъемлющую телекоммуникационную среду разнообразных современных сетевых технологий. Построенная таким образом АПО представляет собой пространственную среду, реализующую следующие основные функции:
· интеграцию разнообразных информационных, коммуникационных, проблемно-ориентированных сервисов и ресурсов федеральных ведомств (например, электронная почта, видеоконференции и т. п.);
· обеспечение гарантированного доступа государственных служащих и граждан к государственным информационным ресурсам независимо от времени и места нахождения и с помощью различных устройств ввода/вывода, коммуникационных приборов, оборудования по обработке информации, а также их комбинации;
· организационно-технологические аспекты, необходимые для поддержки функционирования АПО.
Функциональная структура АПО состоит из трех технологических уровней:
· сетевое программное обеспечение, поддерживающее работоспособность сетевой инфраструктуры (network infrastructure software);
· программного обеспечения среднего уровня (middleware);
· пользовательских приложений (applications).
Сетевое программное обеспечение предоставляет сервис для транспортировки информации различных видов: данных, мультимедиа, документы гипермедиа, графика, информационные контейнеры. Данное ПО должно поддерживать разнообразные типы сетей, посредством которых реализуется доступ пользователей к государственным информационным ресурсам.
Средний уровень включает функции, реализующие универсальные сервисы, используемые приложениями. К числу характерных функций ПО среднего уровня относятся: средства обеспечения защиты информации, службы поддержки справочников, службы имен, сервисы управления данными, учетные системы.
Уровень приложений охватывает спектр проблемно-ориентированных сервисов, предоставление которых конечному пользователю и составляет основное назначение ЭГ. Наиболее известными прикладными сервисами являются: электронная почта, видеоконференции, интерактивная передача речи и видеоданных, оперативных поиск распределенных документов гипермультимедиа.
Целью базовой модели АПО является идентификация интерфейсов, имеющих наибольшее значение для государственного информационного управления. Одним из центральных понятий при построении данной модели служит понятие роли.
Роли исполняются участниками информационного взаимодействия и обладают определенным временем жизни. Роли обладают интерфейсами. Они принимают информационные объекты, изменяют их (добавляют им дополнительные свойства) и передают далее, образуя цепочку, достигающую конечного потребителя. Одна такая цепочка представляет собой государственную функцию.
Модель включает в себя следующие определения:
· роль – деятельность служащего федерального агентства, включаемая в цепь обработки информации государственного управления;
· цепь передачи информационного объекта – дерево ролей, объединяемых для предоставления информации или сервиса конечному потребителю (гражданам);
· структурная роль – роль в основной цели, связанная с деятельностью в области информационного обеспечения и приложений;
· инфраструктурная роль – элемент цепи, связанный с повторным использованием компонентов;
· участник взаимодействия – федеральное агентство или другая организация, выполняющая одну или несколько ролей;
· взаимоотношение между ролями возникает при соединении двух ролей в цепи с целью передачи информационного объекта;
· горизонтальные отношения – отношения между двумя соседними ролями, находящимися в одной цепи (структурное отношение);
· вертикальные отношения – отношения между двумя ролями, находящимися в разных цепях;
· сегмент – часть роли.
Инфраструктурные роли относятся к деятельности, помогающей структурным ролям обмениваться необходимой им информацией. Инфраструктурная роль АПО – обеспечение сетевых сервисов и приложений распределенной обработки и хранения информации.
Существует два альтернативных взгляда на АПО:
· либо АПО находится в области структурных и инфраструктурных ролей;
· либо АПО находится в области только инфраструктурных ролей.
В зависимости от выбора взгляда изменяется степень регламентации внутренней структуры государственных информационных систем. К примеру, первый взгляд на АПО демонстрируют концепции АПО Германии и США, второй – большинство государств, регламентирующих АПО в рамках “концепций взаимодействия” (Interoperability Framework).
Изменяющееся внешнее окружение АПО определяет динамику инфраструктурных ролей:
· микрофункциональная динамика;
· функциональная динамика;
· макрофункциональная динамика;
· эволюционная динамика.
Эволюция инфраструктурных ролей, побуждаемая процессами конвергенции информационных технологий, включает следующие пути модификации вышеназванных четырех ролей:
· автономная эволюция;
· конвергенция двух текущих ролей;
· конвергенция трех текущих ролей;
· конвергенция всех четырех текущих ролей.
Конвергенции сопутствует возникновение новой координирующей и обеспечивающей роли.
Важность использования функциональной (базовой) модели состоит еще и в том, что понятие качества информационных сервисов и приложений проявляется на уровне прав и обязательств сторон взаимодействия, в то время как с чисто технологической точки зрения качество не является значимым аспектом информационного взаимодействия.
4.25.2 Структурная модель АПО
Целью структурной модели является идентификация сервисов и приложений, связанных с ролями. Для предоставления сервиса роль должна объединить информационные ресурсы в применимый набор. Ресурс может предоставляться другой ролью, то есть в свою очередь может быть приложением или сервисом другой роли.
Семантика структурной модели АПО:
· Сервис – однократное взаимодействие между компонентами программной системы, характеризующееся транзакциями между ролями.
· Приложение – повторно используемое взаимодействие между компонентами программной системы, характеризующееся транзакциями между ролями.
· Домен (область ответственности, сфера деятельности) – набор сегментов, находящихся во владении участника взаимодействия.
· Платформа обеспечения сервиса – основа предоставления сервиса, состоящая из набора необходимых сегментов. Может включать несколько доменов.
· Интерфейс сервиса – средства использования сервиса участником взаимодействия, включающие аспекты межролевых отношений – информационные, вычислительные, реализационные.
· Сервисный компонент – компонент интерфейса сервиса.
· Сегмент – сущность, общая для организационного, структурного и функционального моделирования.
Поскольку число возможных сервисов достаточно велико, вводится классификация сервисных компонентов. Определяются следующие классы сервисов:
· инфраструктурные сервисные компоненты;
· сервисные компоненты среднего уровня (middleware);
· сервисные компоненты базового уровня (baseware).
Функциональная и структурные модели АПО предоставляют развитый концептуальный базис и соответствующий язык для описания ролевых свойств активных компонентов архитектуры и их взаимосвязей при проектировании процессов деятельности федеральных ведомств, поддержанных сервисами АПО.
4.35.3 Модель реализации
Формальная стандартизация АПО с помощью профиля заканчивается функциональной моделью, чего обычно не хватает для того, чтобы гарантировать интероперабельность между федеральным ведомством (оператором сервиса) и поставщиками программного обеспечения. В этом случае полезно определять типовые модели реализации, описывающие примеры отображения функций из функциональной модели на базовые информационные технологии.
Данная модель опирается на следующие определения:
· программный модуль – реализация одной или более функций программным способом;
· интерфейс реализации – интерфейс между компонентами реализации, то есть между аппаратными средствами и программным модулем;
· прикладной программный интерфейс – интерфейс реализации между аппаратными средствами и программным модулем;
· программная система – набор программных модулей, работающий как единая сущность;
· сегмент – одна или несколько систем, выполняющих функции, определенные в сегменте функциональной модели.
Реализация подразумевает объединение сегментов инфраструктурной модели, которые включают:
· программные модули среднего слоя;
· прикладные программные модули;
· соединяющие сегменты (например, сегменты доступа, сегменты предоставления сервисов, сегменты администрирования).
4.45.4 Спецификация сценариев
АПО представляет собой объединение многих типов технологий, в частности сетевых, хранения, обработки, транспортировки информации. Поэтому при проектировании конкретных сервисов конкретных ведомств необходимо рассматривать композиции взаимосвязанных функций, программных систем и технологий.
Сценарий представляет собой графическое представление конфигураций функциональных и сетевых элементов АПО, а также их взаимосвязей. Фактически язык сценариев, применяемых для описания технологий АПО и их взаимосвязей, представляет собой схемотехнический язык.
Аппарат сценариев совместно с аппаратом профилей предназначен для функциональной стандартизации технологий АПО. При этом аппарат сценариев обладает большей гибкостью, особенно при условиях, когда создание всех базовых стандартов АПО еще не завершено.
Сценарий рассматривается как элемент стандартизации АПО. Одна из главных задач организации, отвечающей за стандартизацию АПО, состоит в том, чтобы разработать и сопровождать базу стандартных сценариев, описывающих типовые решения по комплексированию технологий АПО.
При этом язык сценариев рассматривается как методологическое средство для систематизации, классификации и стандартизации всех аспектов АПО.
Язык сценариев является графическим языком описания конфигураций технологий АПО и содержит следующие основные графические элементы:
· сетевые элементы;
· функциональные модули;
· интерфейсы;
· связи между взаимодействующими элементами;
· логические связи или ассоциации;
· квалификаторы.
Сценарии позволяют в наглядной форме отражать сложные конфигурации программных компонентов, интерфейсов и сервисов. Конкретизация типов компонентов осуществляется указанием ссылок на спецификации профиля.
Сочетание сценария и профиля называется комплексированием набора технологий и сервисов.
Более того, сценарии могут использоваться в качестве базовых документов в организационных процессах (административных регламентах), а также при разработке спецификаций (стандартов) и собственно технологий АПО.
4.55.5 План стандартизации
Одним из организационных документов, связанных со стандартизацией АПО, является стратегический план стандартизации (standards roadmap). Этот документ является руководством по разработке и развитию стандартов и профиля АПО. В этом стратегическом документе определяются:
· принципиальные свойства информационных технологий АПО;
· состав основных сервисов и программного обеспечения;
· организационная инфраструктура стандартизации технологий АПО.
В данном документе определяется состав основополагающих свойств, которым должны удовлетворять компоненты АПО. Данные свойства становятся базовыми требованиями при разработке профиля и стандартов (в т. ч. при подборе спецификаций в каталог).
При описании свойств учитывается, что:
· АПО описывает открытую систему программного обеспечения, то есть это открытая программная система.
· АПО – это система открытых спецификаций.
· АПО существует в экономических условиях, это экономическая система.
· АПО существует в политических и культурных условиях России.
· АПО – это пользовательская система, то есть у нее есть пользователи, которые ожидают от нее определенный уровень качества ее работы.
Свойства открытой системы включают:
· Переносимость (portability) – легкость переноса программного обеспечения и данных с одной системы на другую.
· Интероперабельность (interoperability) – способность приложений обмениваться информацией и совместно ее использовать.
· Масштабируемость (scalability) – свойство программных продуктов, сервисов эффективно выполнять свои функции при широком диапазоне параметров, определяющих технические и ресурсные характеристики нижележащей платформы и/или поддерживающей среды.
· Мобильность (mobility) – возможность доступа к ресурсам независимо от местоположения пользователя, а также способность инфраструктуры идентифицировать и определять местоположение источника запросов.
· Доступность (availability) – мера возможности использования сервисов или ресурсов.
· Непрерывность обслуживания в пространстве и во времени (nomadicity).
Экономические свойства включают:
· приемлемость по стоимости (affordability) сервисов, предоставляемых федеральными агентствами (отличается от концепции «стоимости владения», предлагаемой компанией Microsoft);
· минимализм (minimalism) – минимальность требований (необходимо и достаточно), необходимых для функционирования АПО (чем больше требований, тем сложнее управлять и использовать, тем больше расходов на систему, то есть АПО).
Свойства национальных особенностей государственного устройства и культуры России:
· возможность поддержки всех национальных языков (алфавитов) народов России;
· правил предоставления информации;
· управляемость (manageability) – возможность для реально действующих федеральных агентств и пользователей (граждан) контролировать распространение и использование информационных ресурсов/.
Качественные свойства:
· качественность (quality) – обеспечение уровня качества, который ожидает получить получатель сервиса;
· эффективность (по ГОСТ Р ИСО 9000);
· результативность (по ГОСТ Р ИСО 9000);
· производительность (performance), включая такие характеристики, как, например, время ответа, пропускная способность, скорость обработки транзакций, скорость регенерации изображений и пр.;
· надежность (reliability) – вероятность того, что программный продукт будет выполнять должным образом свои функции за определенный период времени;
· безопасность (security) – защита ресурсов (аппаратных, программных, информационных) от случайных или преднамеренных действий, вызывающих несанкционированный доступ к ресурсам и нарушение конфиденциальности их использования, модификацию и разрушение ресурсов, а также раскрытие информации;
· легкость использования (usability) продуктов, сервисов, приложений.
В стратегических планах приводится базовая модель классификации стандартов АПО. Как вариант, подобная модель может включать следующие уровни функций:
· область приложений (Application Areas);
· сервисы (Services);
· средства реализации сервисов (Service Implementation Tools).
Уровень “область приложений” включает разнообразные прикладные сервисы. Например, коммуникационные сервисы, интерактивная передача речи и видео, оперативный поиск распределенных документов гипермультимедиа, интерактивный видеосервис (видеоконференции, голосования), совместная виртуальная работа (имеется в виду то, что происходит за “одним окном”).
Уровень “сервисы” развивается по следующим трем направлениям:
· Общие классы сервисов (Generalized Service Categories), используемые для поддержки приложений и объединяющие некоторые наборы фундаментальных строительных блоков в функционально специализированные сервисы или службы.
· Фундаментальные строительные блоки (Fundamental Building Blocks – FBB), которые представляют собой унифицированные средства, позволяющие ускорить разработку приложений и сервисов, а также повысить их надежность.
· Организации-разработчики стандартов (Standard Development Organizations – SDO), то есть организации или их структурные подразделения, ответственные за разработку стандартов средств, фундаментальных сервисов, производных сервисов и приложений.
Под фундаментальными строительными блоками (Fundamental Building Blocks – FBB) понимаются следующие методы:
· Методы доступа (Access Methods) – обеспечивают управляемый доступ к ресурсам.
· Методы адресации (Addressing Methods) – применяют стандарты идентификации местоположения объектов, приложений, каналов и маршрутов навигации данных.
· Методы компрессии (Compression) – используются для оптимизации транспортировки данных.
· Методы информирования граждан о процедуре оплаты (Cost Quotation) налогов, пошлин.
· Методы навигации данных (Data Navigation) – используются для обеспечения перемещения информации через инфраструктуру АПО.
· Методы идентификации (Identification) – используются для различения экземпляров объектов, соединений, пересылаемых блоков данных и оптимизации работы с ними.
· Интернационализации (Internationalization) – используются для настройки приложений на генерацию текстов на требуемых языках.
· Интероперабельности (Interoperability) – используются для обеспечения возможности обмена информацией между функциональными компонентами АПО, а также взаимного использования обмениваемой информации.
· Управления временем передачи (Latency Control).
· Непрерывного обслуживания мобильных потребителей информации (Nomadicity/Mobility) – для сохранения доступа к сервисам независимо от того что пользователь может перемещаться в пространстве и во времени.
· Приоритетного управления (Priority Management) запросами к сервисам.
· Обеспечения приватности (Ownership) – используются для гарантии конфиденциальности передаваемых через АПО данных, а также их защиты от несанкционированного чтения, изменения и копирования.
В другой плоскости уровня «сервисы» лежат общие классы сервисов:
· Сервисы обмена данными (Data Interchange Services) для передачи текстовой информации.
· Сервисы обмена графическими данными (Graphic Services), включая движущиеся образы.
· Сервисы обмена и генерации аудиоинформации (Audio Services).
· Сервисы представления данных (Data Presentation Services) с использованием различных форматов и механизмов преобразования одних форм представления в другие.
· Сервисы управления данными (Data Management Services) для управления хранением и восстановлением данных, используемых средствами GII.
· Сервисы оплаты (Billing Services).
· Сервисы сетевого управления (Network Control Services) – для управления передачей данных через одну или более сетей.
Уровень средств реализации сервисов разбивается на три общих класса сервисов:
· коммуникационные сервисы (Communication Services);
· сервисы стандартизованных структур данных для передачи информации (Standardized Data Structures for Transport of Information);
· стандартизованные механизмы пользовательского взаимодействия (Standardized User Interaction Mechanisms).
Заключение
В результате проведенного исследования с использованием приведенных в настоящем отчете данных были разработаны следующие проекты нормативно-технических документов:
«Архитектура программного обеспечения», описывающая основные принципы и требования к программам, используемым в информационных системах электронного государства;
«Главный профиль АПО», включающий предварительную версию
«Регламент ведения Главного профиля АПО», описывающий открытую процедуру поддержания каталога спецификаций в актуальном состоянии.
Данные документы в целом решают поставленные перед ними задачи и удовлетворяют необходимым требованиям, однако не должны рассматриваться, как конечный и неизменный продукт. Постоянное совершенствование, расширение и уточнение их содержания является естественным и необходимым процессом, заложенным в основу предложенной концепции АПО и единой системы профилей. Возможные направления дальнейшего развития АПО рассмотрены в 4 разделе настоящего отчета.
Основные рекомендуемые мероприятия по внедрению и использованию результатов работ включают:
Создание межведоственного органа (комитета), ответственного за осуществление государственной политики в области АПО и поддержания единой системы профилей АПО;
Публичное обсуждение и уточнение проектов АПО и Главного профиля;
Разработку нормативной документации, необходимой для придания АПО и Главному профилю необходимого юридического статуса, обязательного для всех ведомств, осуществляющих заказ и экусплуатацию ИС ЭГ;
Разработку локальных профилей для конкретных задач и приложений ЭГ.
Внедрение предложенных решений позволит достигнуть значительного
Поскольку архитектура программного обеспечения разрабатывалась с учетом передового опыта, ее текущих уровень можно оценить как в целом соответствующий лучшим достижениями в данной области, в качестве которых рассматриваются концепции SAGA и eGIF. В то же время предложенные решения охватывают более узкую область, чем, например, американская концепция FEA-PMO. Для достижения аналогичного уровня АПО нуждается в увязке с не полностью разработанными в настоящее время более высокоуровневыми документами, определяющими политику государства в области ЭГ в целом.
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
1. ГОСТ Р ИСО/МЭК ТО 10000-1,2,3-99. “Основы и таксономия международных и функциональных стандартов”.
2. 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.
3. 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.
4. 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.
5. ISO/IEC 7498:1996, Information processing systems - Open Systems Interconnection - Basic Reference Model [ITU-T Rec. X.].
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 - Reference Model: Foundation. ITU-T Rec. 903|ISO/IEC 10746-3:1995, Reference Model for Open Distributed Processing - Reference Model: Architecture.
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 DIS 14662, Information technology - Open-edi reference model.
11. ISO/IEC 8613/1:1994, Information technology - Open Document Architecture (ODA) and Interchange Format - Introduction and general principles. [ITU-T Rec. T.411(1993)].
12. ISO 9000-3:1997 Quality management and quality assurance standards -- Part 3: Guidelines for the application of ISO 9001:1994 to the development, supply, installation and maintenance of computer software.
13. ISO 9001:1994 Quality systems -- Model for quality assurance in design, development, production, installation and servicing.
14. ISO 9002:1994 Quality systems -- Model for quality assurance in production, installation and servicing.
15. ISO 9003:1994 Quality systems -- Model for quality assurance in final inspection and test.
16. ISO 9004-1:1994 Quality management and quality system elements -- Part 1: Guidelines.
17. ISO/IEC 12207:1995 Information technology -- Software life cycle processes.
18. ISO/IEC 7498, Information processing systems - Open Systems Interconnection - Basic Reference Model. Part 4: Management framework. [ITU-T Rec. X.].
19. ISO/IEC 10040:1992, Information technology - Open Systems Interconnection - Systems management overview. [ITU-T Rec. X.].
20. ISO/IEC DIS 13244:1996, Information technology - Open Distributed Management Architecture (ODMA).
21. ISO/IEC DTR 10181-1, Information processing systems - Open Systems Interconnection - Security frameworks in open systems: Security frameworks overview.
22. ISO/IEC DTR 13335-1: 1996 - Information Technology Guidelines for the Management of IT Security (GMITS).
23. ISO/IEC 9646-1: 1994/ITU-T X.290: 1994, Information Technology - Open Systems Interconnection - Conformance Testing Methodology and Framework - Part 1: General Concepts.
24. ISO/IEC DIS 13210: 1994, Information Technology - Test methods for measuring conformance to POSIX.
25. ISO/IEC 9241. Ergonomic Standards for Computer Products.
26. ISO/IEC DTR 11017: 1995, Information Technology - Framework for internationalization.
27. ISO/IEC JTC1/SGFS N1261. Directory of ISPs and Profiles contained therein.
28. SAGA. Standards and Architectures for e-government Applications. Version 2.0. KBSt Publication Series. ISSN . Volume 59. December 2003
29. eGIF. Technical Standards Catalogue. VERSION 6.2. Draft for public consultation: May 2005
30. FEAPMO. The Technical Reference Model. V.
31. G. Fisher. Application Portability Profile (APP) The U. S. Government's Open System Environment Profile OSE/1 Version 2.0. NIST Special Publication 500-187. National Institute of Standards and Technology, June 1993.
32. ISO/IEC JTC1/SC 29 N1583, . Meeting Report the First Meeting of ITU-T Joint Rapporteur Group on Global Infrastructure.
33. ISO/IEC JTC1/SC 29 N1580, . Expert from ISO Bulletin: Standards for Global Infrastructure.
34. ITU-T/SG 13/JRG on GII. Report of 60, Report of the Second meeting of the JRG on GII. 6-7 May 1996.
35. ISO/IEC JTC1/SWG-GII N72, 1996, Draft GII Roadmap.
36. Marjory S. Blumentbal. Unpredictable Certaity: The Internet and the Information puter, January 1997, 50-56.
37. Standards for a new age – ICT standardization in Europe. ICTSB Brochure.
38. Report of project 4.1. Principles and framework architecture. ICTSB.
39. How EPII works – guidelines. ICTSB.
40. Transmission and multiplexing. Access Networks for residential customers. ETSI Guide (EG) 202 306.
[1] По ГОСТ 34.003-90 автоматизированная система – это «система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций».
[2] Хотя в ГОСТ 34.003-90 и определено понятие «пользователь», как «лицо, участвующее в функционировании АС или использующее результаты ее функционирования», но всем остальным корпусом стандартов области АС оно методически поддержано очень слабо. Так, ГОСТ 34.601-90 трактует понятие «пользователь» исключительно как синоним понятия «Организация-заказчик». В ГОСТ 34.602-89 предусмотрены разделы ТЗ, устанавливающие требования к персоналу и (отдельно) к обслуживающему персоналу (что вообще не согласуется с определениями ГОСТ 34.003-90), а требования к системе формулируются в терминах «автоматизируемых процессов». Структура документа «Руководство пользователя» по РД 50-34.698-90 явно рассчитана персонал, связанный отношениями подчиненности с эксплуатирующей систему организацией. Не нашли отражения в стандартах такие понятия, как, например, «ролевая модель», без которой крайне сложно формулировать требования к пользователям в современном понимании этого термина.
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 |
