5.6. Оценка, стыковка и поддержка системы

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

Оценивают систему по следующим критериям:

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

- критерии приглашенных экспертов (оценка решений, предлагаемых системой, сравнение их с собственными решениями, оценка подсистемы объяс­нений);

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

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

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

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

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

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

Поддержка экспертной системы необходима, если проблемная область, лежащая в основе экспертной системы, склонна к изменениям.

6. Пример разработки прототипа экспертной системы для решения задач управления качеством

Для примера возьмем одну из областей управления качеством – внутренний аудит, и выполним действия, указанные в главе 5 пособия (п. 5.3-5.4).

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

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

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

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

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

Таблица 6.1

План разработки прототипа экспертной системы «Разработка корректирующих действий»

Стадии разработки	Ответственные	Сроки
Идентификация проблемы	Начальник цеха Фамилия И. О. (эксперт) Должность Фамилия И. О. (инженер по знаниям)	08.09.__ - 18.09.__
Извлечение знаний	Начальник цеха Фамилия И. О. (эксперт) Должность Фамилия И. О. (инженер по знаниям)	18.09.__ - 26.11.__
Структурирование знаний	Должность Фамилия И. О. (инженер по знаниям)	26.11.__ - 15.12.__
Формализация знаний	Должность Фамилия И. О. (инженер по знаниям) Должность Фамилия И. О. (программист)	15.12.__ - 28.01.__
Реализация прототипа	Должность Фамилия И. О. (программист)	28.01.__ - 10.03.__
Тестирование	Начальник цеха Фамилия И. О. (эксперт) Должность Фамилия И. О. (инженер по знаниям) Должность Фамилия И. О. (программист) Начальники цехов Фамилии И. О. (пользователи)	10.03.__ - 20.03.__

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

Цель экспертной системы «Разработка корректирующих действий» – распространение опыта по анализу выявленных несоответствий, определению их причин и выбору корректирующих действий. Необходимые ресурсы – время и люди, указанные в плане разработки, а также ЭВМ. Источниками знаний могут быть дополнительные эксперты, т. е. начальники цехов и внутренние аудиторы, а также документированная процедура корректирующих действий, если таковая имеется на предприятии. Допустим также, что аналогичных экспертных систем нет.

На стадии извлечения знаний для передачи знаний от эксперта инженеру по знаниям используются методы, указанные в п. 5.4.2. Для рассматриваемой экспертной системы больше подходят такие методы, как круглый стол, интервью и анализ документов.

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

В экспертной системе «Разработка корректирующих действий» будет использоваться терминология управления качеством (ГОСТ Р ИСО 9000 – 2001) и специфическая терминология подразделения, для которого разрабатывается прототип экспертной системы. Основными понятиями, составляющими структуру базы знаний в создаваемой системе, являются несоответствие, причина несоответствия, корректирующее действие.

В соответствии с ГОСТ Р ИСО 9000 – 2001 Системы менеджмента качества. Основные положения и словарь:

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

Корректирующее действие – действие, предпринятое для устранения причины обнаруженного несоответствия или другой нежелательной ситуации.

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

Рис. 6.1. Поле знаний экспертной системы

«Разработка корректирующих действий»

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

На стадии формализации знаний выбирается одна из моделей представления знаний, которые описаны в п. 4.3 пособия. Для экспертной системы «Разработка корректирующих действий» наиболее применима продукционная модель, основанная на правилах (ЕСЛИ …, ТО …). База правил системы будет содержать правила, имеющие следующую структуру.

ЕСЛИ «несоответствие N», ТО «причина N_п».

ЕСЛИ «причина N_п», ТО «корректирующее действие N_пк».

ЕСЛИ «несоответствие N» и «причина N_п», ТО «корректирующее действие N_пк».

Примерами этих правил могут быть следующие.

ЕСЛИ «отсутствует документ СМК в подразделении», ТО «не достаточно определена ответственность за управление документами».

ЕСЛИ «не достаточно определена ответственность за управление документами», ТО «документально зафиксировать ответственность за управление документацией и довести информацию до исполнителей».

ЕСЛИ «отсутствует документ СМК в подразделении» и «не достаточно определена ответственность за управление документами», ТО «документально зафиксировать ответственность за управление документацией и довести информацию до исполнителей».

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

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

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1 Гаврилова Т. А. Базы знаний интеллектуальных систем: Учебное пособие / Т. А. Гаврилова, В. Ф. Хорошевский. – СПб.: Питер, 2001. – 382 с.

2 Ясницкий Л. Н. Введение в искусственный интеллект: Учебное пособие / Л. Н. Ясницкий. – М.: Академия, 2005. – 174 с.

3 Новикова В. А. Искусственный интеллект и экспертные системы: Учебное пособие / В. А. Новикова, Е. Ю. Андреева, Д. К. Туйкина. – Курск: КГУ, 2004. – 45 с.

4 Марселлус Д. Программирование экспертных систем на Турбо Прологе: Пер. с англ. – М.: Финансы и статистика, 1994.

5 www.intuit.ru

6 www.ai.tsi.lv

7 Попов Э. В. Экспертные системы: Решение неформализованных задач в диалоге с ЭВМ. – М.: Наука, 1987.

8 Уотермен Д. Руководство по экспертным системам. – М.: Мир, 1989. – 388 с.

9 Моисеев В. Б. Представление знаний в интеллектуальных системах // Информатика и образование. – № 2, 2003. – С. 84-91.

10 Осипов Г. С. Интеллектуальная технология для построения экспертных систем: Учебное пособие в 2 ч. / Г. С. Осипов, Е. П. Куршев, С. И. Комаров. – Рыбинск: РГАТА, 1997. – Ч. 2. – 52 с.

11 Минский М. Л. Фреймы для представления знаний. М.: Энергия, 1979.