CC BY-NC-ND
84
КЛАССИФИКАЦИЯ ОПЕРАЦИОННЫХ РИСКОВ ПРИ СЕРВИСНО-ОРИЕНТИРОВАННОМ ПОДХОДЕ К СОЗДАНИЮ ИНФОРМАЦИОННОЙ СИСТЕМЫ
И.В. Пырлина,
преподаватель кафедры корпоративных информационных систем Национального исследовательского университета «Высшая школа экономики» Адрес: г. Москва, ул. Кирпичная, д. 33/5 E-mail: [email protected]
В статье проведено исследование операционных рисков в рамках сервисного подхода создания информационных систем (ИС) и предложен подход к их классификации, основывающийся на ошибках систем, которые являются поставщиками сервисов для типового приложения с сервисно-ориентированной архитектурой. С использованием предложенной классификации собрана статистика сообщений об ошибках за 5 лет по двум предприятиям нефтегазовой и металлургической отрасли. Проведен опрос экспертов с целью определения убытков от исследованных рисков и приведена оценка возможного урона.
V ^
Ключевые слова: операционные риски, убытки, классификация ошибок, сервисно-ориентированная архитектура, нефтегазовая и металлургическая отрасль.
Введение
Современная развивающаяся компания с каждым годом совершенствует и оптимизирует внутренние процессы и процедуры, чтобы достичь наиболее высокого уровня продаж, повысить качество и эффективность работы компании, а также одновременно сократить издержки работы и производства. Для этого необходимо внедрять и использовать новейшие технологии и системы. Причем совершенствуются не только технологии производства продукции и услуг, но и системы, поддерживающие вспомогательные процессы ор-
ганизации, к ним относятся и системы с сервисноориентированной архитектурой приложения.
Для того чтобы определить эффективность новой применяемой технологии или архитектуры решения, такой как сервисно-ориентированная архитектура, важно определить не только прибыль, но и стоимость убытков от ее реализации. Обычно к убыткам информационных систем относятся затраты на их внедрение и поддержку (в том числе затраты на серверное оборудование, программные средства, персонал и т.д.)1. Однако необходимо учитывать не только планируемые издержки, но и внеплановые
затраты, к которым относятся убытки от реализации рисков работы информационных систем. Такие риски называются операционными. Они возникают достаточно часто и суммарно могут представлять ощутимую статью расходов в бюджете ИТ.
Современные информационные технологии позволяют дать более четкую оценку убытков, появившихся в результате реализации операционных рисков на основе статистического анализа. Операционные риски в рамках сервисного подхода создания информационных систем могут возникать из-за недостаточной квалификации персонала (например, при вводе некорректной информации или при неправильной интерпретации результатов) или несанкционированных действий персонала, сбоев в работе информационных систем или сбоев в работе сети, недостатков памяти и перебоев в работе серверного оборудования.
В данной статье автор предлагает подход определения типов операционных рисков от использования приложений с сервисно-ориентированной архитектурой. Проверка эффективности предложенного подхода осуществляется на базе статистики по двум предприятиям. За исследуемый 5 -летний период в нефтегазовом предприятии было зафиксировано 820 ошибок в разных компонентах систем, в то время как за 4-летний период (2007-2010 гг.) в металлургическом предприятии было выставлено 916 сообщений об ошибках. На базе полученных ошибок и анализа существующих подходов была разработана классификация ошибок программного обеспечения (ПО). Задача этой работы — создать классификацию операционных рисков компании, внедряющей сервисно-ориентированные системы.
В работе под операционными рисками2 понимаются потенциальные убытки, возникающие из-за ошибок работы ресурсов информационных систем с сервисно-ориентированной архитектурой, т.е. ошибок ПО, аппаратного обеспечения и неправильной работы человеческих ресурсов.
В центре сервисно-ориентированной архитектуры приложений лежит понятие сервиса (бизнес-сервиса или технического сервиса). Под бизнес -сервисом в данном случае понимается область деятельности предприятия, где реализация приложений с сервисно-ориентированной архитектурой будет иметь наибольшую выгоду для предприятия. Мы определяем бизнес-сервис как совокупность:
1. функций, объединенных по критичным для бизнеса атрибутам,
2. системных операций, обернутых в шеЪ-сер-висную оболочку,
3. технических ресурсов, реализующих приложения, на базе которых работают технические сервисы (например, «еЪ-сервисы).
Под техническим сервисом, согласно классическому определению, понимаются автономные, модульные, «самоописываемые» приложения, которые предоставляют набор выполняемых функций каждому, кто их запрашивает [9]. В данном подходе технический сервис определяется в виде прикладных компонент или технических компонент, которые поддерживают работу бизнес-сервиса.
Исходя из введенных определений, операционные риски сервисно-ориентированных приложений следует определять на базе используемых ресурсов бизнес-сервиса.
1. Типы операционных рисков
Операционные риски в рамках информационных систем с сервисно-ориентированной архитектурой тесно связанны с ресурсами, потребляемыми этими приложениями, в частности с ресурсами бизнес-сервисов. Среди них стоит выделить (рис. 1) следующие типы:
♦ Человеческие ресурсы — сотрудники, вовлеченные в процесс или в сервис. На рисунке ниже отражены все ресурсы типового бизнес-сервиса. С точки зрения человеческих ресурсов, типовой бизнес-сервис включает представителей бизнес-подразделений и экспертов, отвечающих за ключевые операции сервиса, владельцев процессов и данных, авторов заявок/документов и их согласующих, также администраторов приложений сервиса.
♦ Прикладные ресурсы — прикладные программы, которые имеют возможность публикации/поддержки технических сервисов, к их числу относятся не только ПО, но и системы аппаратного обеспечения, а именно,
— Подсистема доступа — различные технологии пользовательского интерфейса для работы с системой («Тонкий» клиент на базе ^ёЪ-технологий, и «Толстый» клиент в виде прикладных 'МпёошБ-приложений),
1 Для оценки затрат информационных систем используются, например, такие методологии, как анализ Совокупной Стоимости Владения (или ТСО) [7].
2 Общее определение термина «операционный риск» приводится в [8, стр.185].
г— Человеческие ресурсы
Эксперт,
Администратор
Автор
Владелец,
Согласующий
Представители бизнес-подразделений
Программное обеспечение
Подсистема доступа (интерфейс пользователя)
Толстый клент Тонкий клиент
Прикладное программное обеспечени
Программа 1 1=1 Программа 2 Программа 3
■________________Ш
Связующее программное обеспечение
Инфраструктурное ПО
Системное ПО 1 Системное ПО 2 Системное ПО 3 Системное ПО 4 Системное ПО 5
— Аппаратное обеспечение
Сервер Сервер Сервер Сервер Сервер
Рис. 1. Ресурсы
— Прикладное ПО — аналитический аппарат систем,
— Связующее ПО, предназначенное для организации информационного обмена между всеми системами и подсистемами,
— Инфраструктурное ПО — программы, которые предназначены для организации правильной работы серверного оборудования, а также программного обеспечения, которые устанавливается на сервере.
♦ Технические ресурсы — серверы, оборудование. С учетом вышеизложенного выделяются следующие группы операционных рисков:
■ф- Риск персонала — риски получения ущерба от некорректной или неадекватной работы персонала, а также риски, связанные с несанкционированной работой персонала,
Ф Риски прикладных систем — риски получения ущерба от выхода из строя любой компоненты программного обеспечения. Данный ущерб получается в результате сбоя работы или ошибок ПО, ■^Технические риски — риски, связанные с выходом из строя аппаратного обеспечения (т.е. любого оборудования, на котором установлено ПО),
бизнес-сервиса.
Под ошибкой ПО или программной ошибкой [5] понимается не достижение или отличие от запрограммированного результата, ради которого была создана программа. Ошибки ПО включают в себя:
• дефекты в ходе исполнения программы и определения данных,
• неправильный результат исполнения программы,
• некорректные действия человека, порождающие некорректный результат.
Группа рисков прикладных систем является наиболее крупной из перечисленных выше. Поэтому прежде чем оценивать возможный ущерб от приведенных групп рисков, определим более детально классификацию ошибок ПО, которая расширит общую классификацию операционных рисков приложений с сервисно-ориентированной архитектурой.
2. Обзор классификаций ошибок программного обеспечения
Как известно, качество композитных приложе-ний3, обращающихся к сервисам других систем, зависит от количества ошибок не только самого
3 Мы определяем композитное приложение как приложение, которое использует данные и функции, предоставляемые платформами и приложениями в виде сервисов, комбинируя их в ориентированные на пользователя процессы и представления.
композитного приложения, но качества сервисов, предоставляемых другими приложениями ландшафта. Поэтому достаточно будет сформировать классификацию ошибок программного обеспечения, которое будет использоваться сервисными приложениями.
Существует большое количество подходов классификации ошибок ПО [1,2,3,4,6]. Наиболее распространенные подходы предлагают классифицировать возникающие ошибки
♦ По приоритету и серьезности их ущерба (классификация, применяемая в компании SAP AG)
— Самый высокий приоритет
— Высокий приоритет
— Средний приоритет
— Низкий приоритет
♦ По типу приложения, в котором возникла ошибка (или как указано в [1,2] по «месту их возникновения»)
— Ошибки пользовательского интерфейса
— Ошибки прикладного ПО
— Ошибки связующего ПО (или «ошибки обработки интерпретации данных» по [1])
— Ошибки системного ПО
— Ошибки аппаратного обеспечения (или аппаратные ошибки [2])
♦ По причинам возникновения ошибок (в [3] автор предлагает использовать классификацию Beizer)
— Функциональные ошибки
— Системные ошибки
— Процессные ошибки
— Ошибки данных
— Ошибки кода
— Ошибки документации
— Другие ошибки, причина которых не установлена.
♦ Также есть классификации по месту ошибок в жизненном цикле ПО (в соответствие с ГОСТ 34.601 -90 стадии создания АС — формирование требований, разработка концепции АС, техническое задание, эскизный проект, технический проект, рабочая документация, ввод в действие, сопровождение АС). Однако классификация по жизненному циклу приложения не подходит в данном случае, поскольку мы рассматриваем только приложения, находящиеся в эксплуатации. Именно такие приложения как конечный продукт интересны с точки зрения обоснования их эффективности и производительности в рамках построения SOA4-стратегии.
4 SOA — Service-Oriented Architecture.
3. Новая классификация ошибок программного обеспечения и операционных рисков
Почти все рассматриваемые в рамках анализа методы не имеют статистической информации, отражающей эффективность применяемых классификаций. Только в [4] приводятся классификации с демонстрацией результатов статистических исследований производственного окружения или индустрии ИТ, однако задача этих исследований
— проверить собственную классификацию ошибок программного кода и использовать эти данные для дальнейшей разработки систем (в основном являющихся собственными разработками). Классификации авторов [3,4] либо избыточны, либо преследуют специфические цели классификации программ на фазах проектирования, тестирования и реализации. К тому же в [4] приводятся недостатки существующих классификаций ошибок.
В отличие от этого в данном исследовании собиралась информация по типам ошибок систем класса ERP (т.е. крупных стандартных систем) в ландшафте обследуемых предприятий, их приоритетности, частоте возникновения и сложности устранения (т.е. длительность).
Мы предлагаем следующую классификацию ошибок программного обеспечения, которую можно применять ко всем типам программных приложений в рамках сервисно-ориентированной архитектуры
Ф Основная категория классификации
— Ошибки ввода (инициализации данных) — вывода результатов (или ошибки пользовательского интерфейса) — ошибки в определении констант, переменных, в представлении результатов работы системы.
— Функциональные ошибки — ошибки в части программы, где происходит преобразование переменных, реализация логики решения.
— Ошибки связующего ПО (или «ошибки обработки интерпретации данных» по [1]) включают в себя проблемы при передаче данных между подпрограммами, искажение передаваемой информации или ошибки при обмене сообщениями.
— Ошибки данных — ошибки приложения, которые изменяют данные в любом типе хранилища данных (данный класс введен автором [6] для шеЪ-приложений, что применимо и для сервисноориентированной архитектуры).
— Системные ошибки — ошибки программного окружения, конфигурации сервера, проблемы тайм-аута, ошибки памяти, ошибки прав пользователей, проблемы производительности, ошибки сети, ошибки баз данных, ошибки операционной системы и аппаратного обеспечения (включают проблемы тайм-аута5, ошибки памяти6, и также проблемы нехватки ресурсов при повышении нагрузки), а также ошибки при развертывании и сопровождении систем и обеспечении безопасности.
— Не ошибка — к этой группе относятся ошибки, которые были устранены без изменения настройки или изменения кода, ошибки в описании решения, или отсутствие описания решения.
■ф- Также при классификации ошибок мы будем указывать приоритет ошибки:
— Очень высокий (1) — ошибки, которые имеют или могут оказать критическое влияние на продуктивную эксплуатацию системы, на бизнес процессы и операции, а также могут привести к краху или полной остановке работы системы;
— Высокий приоритет (2) имеют ошибки, которые оказывают существенное влияние на бизнес-операции, а также ведут к заметному снижению производительности системы;
— Средний приоритет (3) имеют ошибки, которые оказывают влияние на функциональность системы и соответственно могут повлиять на бизнес-операции, однако не являются критическими;
— Низкий приоритет (4) получают ошибки, прозрачные для пользователя. Например, ошибки пользовательского интерфейса не нарушают возможность использования системы, однако не удобны для использования и требуют устранения.
•ф Устранение ошибки или длительность рассмотрения — то, как быстро была решена проблема, характеризует сложность проблемы. Длительность рассчитывается от даты подачи заявления до даты, когда проблема считается решенной, т.е. выставлен статус «completed».
Полученная статистика в результате применения классификации ошибок при внедрении сервисно-ориентированных приложений для двух
предприятий металлургической и нефтегазовой отрасли приведена в таблице (табл. 1. Ошибки ПО нефтегазового клиента за 2006-2010 (выборка)). Здесь приведена лишь выборка наиболее показательных сообщений об ошибках из общей статистической базы.7
Таблица 1.
Ошибки ПО нефтегазового клиента за 2006-2010 (выборка)
Короткий текст ошибок
1 Credential for the Adobe Interactive Forms scenario Ошибки ввода -вывода результатов 4
2 Anonymous users don't see KM content Ошибки ввода -вывода результатов З
З Error with system data editing in support portal Ошибки ввода -вывода результатов З
4 Not all components are inserted after BOM explosion Функциональные ошибки 2
5 Create new cancellation document after cancellation Функциональные ошибки 2
6 Report 'Price Comparison' fails Функциональные ошибки 2
7 Different configuration screens in Integration Builder Ошибки связующего ПО 4
В Middleware — Bdoc validation error Ошибки связующего ПО 2
9 Integration Directory-Communication Channel not found Ошибки связующего ПО З
10 Authority for master data in BI Ошибки данных З
11 Master data time interval error Ошибки данных 2
12 product catalog replication Ошибки данных 2
1З Clustering information in SDB Системные ошибки 2
14 High CPU consumption by a server node Системные ошибки 2
15 OutOfMemoryError in during export Системные ошибки З
16 SAP Solution Manager Preparation Service Не ошибка З
17 Incorrect create SD message from ECP system Не ошибка З
1В Test message Не ошибка 4
У каждого сообщения об ошибке собиралась дополнительно к основной категории информация по приоритету и длительности устранения ошибок, чтобы понять важность и критичность возникающих ошибок в каждой группе. Суммарно собрана статистика за 2006-2010 у нефтегазового и металлургического предприятий (табл. 2).
5 Мы определяем тайм-аут как перерыв в работе приложений, связанный со слишком высокой нагрузкой на него.
6 Ошибки памяти — ошибки, связанные с некорректным обращением к оперативной памяти.
7 Автор приносит свои извинения за текст сообщений на английском языке. Система сбора сообщений об ошибках работает только на английском языке и соответственно предъявляет языковые требования к выставляемым сообщениям.
Таблица 2.
Статистика по двум компаниям
В таблице (табл. 3) и на диаграмме (диаграмма 1) ниже приведены итоговые результаты по количеству собранных ошибок. Для примера в каждой группе в таблице указано по 3 ошибки. Рисунок же отражает итоговые значения по всем собранным сообщениям по все группам ошибок. На базе приведенных результатов видно, что наибольшее количество ошибок за 5-летний срок наблюдается в категориях «функциональные ошибки» и «системные ошибки». Данная статистика показывает, что внедренные системы всегда имеют недостатки или недоработанные функции сразу после выхода в продуктивную эксплуатацию, а также вероятно были сделаны ошибки при первоначальной оценке необходимого системного ландшафта и при настройке функциональности. Важно также отметить, что статистика демонстрирует первые 5 лет эксплуатации информационных систем сразу после их внедрения.
Таблица 3. Статистика по каждой группе ошибок
Основная Количество ошибок 1%
(2006-2010) 2010 2009 1 2008 2007 2006 Итого 1%
1. Ошибки ввода (инициализации данных) - вывода результатов 21 21 95 22 3 168 10
2. Функциональные ошибки 1-0 СО со 269 166 68 62 787 48
3. Ошибки связующего ПО 79 26 21 12 2 110 7
4. Ошибки данных 29 37 19 9 10 92 6
5. Системные ошибки 170 114 86 53 24 410 25
6. Не ошибка 9 26 20 10 5 71 4
На диаграмме (диаграмма 1) отражена проанализированная статистика за 2006-2010 гг. в рамках каждого класса. На первой диаграмме показано количество ошибок в каждом классе и штриховкой обозначены приоритеты полученных заявок. Самое большое количество заявок попадает в средний приоритет, на втором месте высокий приоритет. Крайне редко выставляются заявки низкого или очень высокого приоритета. На второй диаграмме отражена также средняя длительность устранения ошибки для каждой категории ошибок. Общая длительность устранения ошибок в среднем мала. Самыми длительными являются сроки устранения в
Рис. 1. Диаграмма: основные категории, приоритет и статус (2006-2010).
ГПЗ 1. Риски персонала № 2. Риски прикладных систем
-ГСП 2.1 Риски ввода-выводв данных
2.2 Функциональные риски
2.3 Риски связующего ПО Ш 2.4 Риски обработки данных Щ 2.5 Системные риски
га 3. Технические риски
КЛАСС: Риски ввода-вывода данных
АТРИБУТЫ .ЗНАЧЕНИЯ
- Короткий текст ошибки. ...Anonymous users don't
see KM content
- Приоритет ...Высокий
- Длительность
устранения ошибки ...8 дней
- Операционные убытки.. ..51864 руб/день
- Исполнитель ...Иванов В.А.
- Компонент системы ...SAP NetWeaver Portal
Рис. 2. Классификация операционных рисков при сервисно-ориентированном подходе к созданию ИС.
категории Не ошибка (в среднем 26 дней), Ошибки ввода-вывода результатов (в среднем 22 дня) и Системные ошибки (в среднем 21 день). Минимальные сроки устранения ошибок в категории Ошибки связующего ПО — 10 дней в среднем.
Предлагается детализировать классификацию операционных рисков при сервисно-ориентированном подходе к созданию информационных систем на основе типов ошибок программного обеспечения, приведенных выше. Каждому идентифицированному типу ошибок соответствует класс риска, основные атрибуты которого зависят от приоритета ошибок и длительности устранения ошибок. Соответствующая классификация рисков приобретает следующий вид (рис. 2).
На базе выявленных категорий ошибок (или операционных рисков) можно провести анализ операционных убытков информационных систем с сервисно-ориентированной архитектурой.
4. Операционные убытки при реализации рисков
Автором был проведен опрос с целью оценки убытков при отсутствии решения по выставленным сообщениям об ошибках. Экспертами компании БАР была выставлена оценка времени использования в день систем, на которые были выставлены сообщения об ошибках в соответствующих предприятиях, а также количество пользователей, использующих одновременно данную систему в день. Оценка проводилась по выборке сообщений, представленных выше. На базе полу-
ченных оценок был произведен анализ операционных убытков (в руб. в день, табл. 4)
Кроме того, при расчете величины убытков были использованы три варианта стоимости человекодня. Каждый уровень соответствует трем ролям сотрудников (инженер, ведущий инженер, менеджер). Разные приоритеты сообщений об ошибках в среднем по статистике выставляются разными группами пользователей. В среднем здесь наблюдается зависимость приоритета сообщения от роли пользователя
— низкому приоритету ошибок соответствует стоимость дня инженеров,
— среднему и высокому приоритетам мы поставили в соответствие стоимость ведущего инженера,
— очень высокий приоритет оценен стоимостью дня менеджера.
Стоимость системных ошибок будет зависеть от стоимости дня администратора. Также стоит отметить, что стоимость указанных дней включает в себя не только заработную плату соответствующих специалистов, но и административные затраты на сотрудников и налоги. Таким образом, убытки за каждый день не решения проблемы, указанной в сообщении об ошибке, расчитываются по формуле
Убытки = V • Qu • Ж1 , где
и — % использования функции в день,
Qu — количество сотрудников, использующих данную функци ональность,
— стоимость человеко-дня в зависимости от роли и приоритета сообщения.
Таблица 4.
Операционные убытки нефтегазового клиента за 2006-2010 (выборка)
Номер Короткий текст ошибок Основная категория Прио- ритет Устранение Операционные ошибок (дни) убытки (в руб./день)
1 Credential for the Adobe Interactive Forms scenario Ошибки ввода - вывода результатов 4 1 5 1Вб
2 Anonymous users don't see KM content Ошибки ввода - вывода результатов З В 51 Вб4
З Error with system data editing in support portal Ошибки ввода - вывода результатов З В 51 Вб4
4 Not all components are inserted after BOM explosion Функциональные ошибки 2 21 бб бВ2
5 Create new cancellation document after cancellation Функциональные ошибки 2 11 бб бВ2
б Report 'Price Comparison' fails Функциональные ошибки 2 Зб 1ЗЗ Зб4
7 Different configuration screens in Integration Builder Ошибки связующего ПО 4 4 15 559
В Middleware - Bdoc validation error Ошибки связующего ПО 2 1 бб бВ2
9 integration Directory-Communication Channel not found Ошибки связующего ПО З 2 77 79б
10 Authority for master data in BI Ошибки данных З З9 25 9З2
11 master data time interval error Ошибки данных 2 1 бб бВ2
12 product catalog replication Ошибки данных 2 5 ЗЗ З41
1З Clustering information in SDB Системные ошибки 2 14 51 Вб4
14 High CPU consumption by a server node Системные ошибки 2 7 51В бЗб
15 OutOfMemoryError in during export Системные ошибки З 4 2 59З
Дополнительно в таблице отражено общее количество дней, которое потребовалось для устранения ошибки, что дает представление об общей величине операционных убытков ИТ и по сути является примером операционных убытков прикладных систем с сервисно-ориентированной архитектурой.
Заключение
В работе предложен подход к классификации типов операционных рисков от использования приложений с сервисно-ориентированной архитектурой. Установлено, что при их классификации стоит использовать как типы ресурсов, так и категории программного обеспечения. Такой подход расширяет
классификацию операционных рисков и облегчает поиск, сбор и анализ статистики операционных рисков. Кроме того, мы опробовали и привели результаты использования разработанной классификации на статистических данных двух компаний, что позволяет судить о ее эффективности. И, наконец, удалось оценить операционные убытки при отсутствии решения по выставленным сообщениям об ошибках. Определенные в данном исследовании группы операционных рисков послужат основой для модели операционных рисков систем с сервисно-ориентированной архитектурой. Собранная статистика будет использоваться при имитации работы систем данного типа.
Автор благодарен профессору Ф.Т. Алескерову за постановку задачи. ■
Литература
1. Канер С., Фолк Дж., Нгуен Е.К. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений. — ДиаСофт, 2001.
2. Майерс Г. Надежность программного обеспечения. — М.: Мир, 1980.
3. Krawczyk H., Wiszniewski B., Mork H. Classification ofsoftware defects in parallel programs // HPCTI Progress Report nol, April 1995.
4. Ostrand T.J., Weyuker E.J. Collecting and Categorizing Software Error Data in an Industrial Environment // The Journal of Systems and Software 4, 1984. P. 289-300.
5. IEEE Standard Glossary of Software Engineering Terminology, IEEE Std 729-1983 // Inst. Electrical and Electronics Eng., New York, 1983.
6. Guo Y., Sampath S. Web Application Fault Classification—An Exploratory Study // ESEM’08 Proceedings of the Second ACM-IEEE international symposium on Empirical software engineering and measurement ACM New York, NY, USA, 2008. URL: http://portal.acm.org/citation.cfm?id=1414060
7. SAP TCO Framework: A Framework to Reduce Total Cost of Ownership // SAP White Paper. 2005. SAP AG.
8. Алескеров Ф.Т., Андриевская И.К., Пеникас Г.И., Солодов В.М. Анализ математических моделей Базель II. — М.: Физматлит, 2010.
9. Haas H., Brown A. Web Services Glossary. W3C Working Group Note 11 February 2004. — W3C. URL: http:// www.w3.org/TR/ws-gloss/
