Структуризация функциональных характеристик программных средств в задачах поддержки принятия решений
,
Работа выполнена при финансовой поддержке Российского фонда фундаментальных исследований (проект N ).
Аннонтация: В данной работе проведены исследования двух рабочих систем поддержки принятия решения. Выявлениы их характерные черты и особенности.
Введение
Более 20 лет назад великий программист того времени
Дж. Мартин сделал гениальное предсказание о приближении эры «Программирование без программистов». И вот, не смотря на скептическое отношение многих экспертов к этому прогнозу, предсказанная эра наступила. В броском лозунге, конечно не очень аккуратно сказано. Имеются в виду, что будут нужны прикладные программисты. Системные программисты пишут такие программы, что обычным пользователям достаточно вводить некоторый набор параметров, а прикладные программисты становятся не нужны.
За это конечным пользователям придется заплатить свободой «заказывать музыку». Сейчас на рынке программного обеспечения мы имеем большое число программных продуктов для решения различных прикладных задач. При этом в большинстве случаев для более-менее сложных задач никакой продукт не подходит полностью и мы стоим перед выбором одного из 3-х плохих вариантов решений:
1) попытаться создать свой программный комплекс, в котором будут учтены все требования и спецификации. Этот вариант требует больших ресурсов, временных, финансовых и др. Как правило не применим за счастливым исключением некоторых очень амбициозных проектов.
2) Выбрать из имеющихся N продуктов наиболее подходящий. В этом случае, поскольку сложные задачи они потому и сложные, что их еще не решали, выбранный продукт сможет охватить только часть проблем. Что делать с остальными проблемами непонятно, так как программные комплексы обычно закрыты для пользователей, а надеяться, что разработчики смогут в приемлемое время решить ваши проблемы, очень проблематично.
3) Имеется еще один вариант – попытаться проинтегрировать имеющиеся программные продукты, чтобы использовать все преимущества (для данной задачи) каждого продукта [8]. Этот вариант имеет свои недостатки тоже: необходимо купить (получить лицензию, добыть) несколько программных систем; провести аналитическое исследование по преимуществам и недостаткам каждого продукта и самое сложное осуществить интеграцию продуктов.
Данная статья посвящена попыткам использовать третий вариант в предметной области выбора систем поддержки принятия решений (СППР) или как широко распространено в англоязычной литературе Decision Support Systems (DSS) [7].
В настоящее время все большое количество решений принимается в результате компьютерного анализа больших объемов информации. Вследствие этого возрастают требования к качеству выполнения этой аналитической работы для обоснования принимаемых решений и к созданию соответствующих инструментальных средств. При подготовке принятия решений, особенно в чрезвычайных ситуациях, привлекаются специалисты – эксперты, консультанты, системные аналитики. Их задача состоит в разработке альтернативных решений, выявлении достоинств и недостатков принимаемых решений.
Эффективным средством повышения качества принимаемых решений специалистами являются системы поддержки и принятия решений (СППР). СППР объединяют в себе возможности современных компьютерных систем и умение человека при решении слабоструктуризированных и неструктуризированных проблем. Область применения СППР на данных момент охватила большое количество сфер человеческой деятельности: бизнес, производство, финансы, науку и т. д.
Популярность СППР постоянно растет и это связано с появлением новых технических и программных средств, которые позволяют снизить расходы на создание и эксплуатацию систем. Не маловажен также тот факт, что в настоящее время происходит сближение человека и компьютерных систем в области управления[6].
Естественно, СППР не может заменить человека, автоматизируя процедуру принятия решения, но может обеспечить его различного вида помощью в области проблемы принятия решения.
В современных условиях объемы данных, описывающие параметры различных предметных областей значительно возрастают. СППР могут оказать значительную помощь пользователям в обработке и анализе данных, причем учитывая разнохарактерность информации [2].
Разработка и реализация СППР на данный момент превратилась в большую индустрию, и сейчас наблюдается лавинообразный рост интереса к продуктам этого класса, обусловленный исключительно практическими соображениями [3].
Поддержка принятия решений заключается в возможности составления произвольного, непредсказуемого запроса нетехническим специалистом и представления результатов в удобном для анализа виде. В худшем случае скорость ответа исчисляется минутами. Большинство компаний и предприятий используют в качестве СППР специалистов отдела информационных технологий или программистов [1]. Как правило, полученный от них через некоторое время (в лучшем случае измеряемое часами) результат дополнительно обрабатывается. На выполнение подобных процедур уходит не только время аналитика, но и время других сотрудников. Все больше компаний начинает задумываться о реальных финансовых потерях, вызванных производственными задержками. СППР значительно сокращают затраты на получение информации и время реакции на события.
Системы поддержки принятия решений DSS предназначены для персонала, отвечающего за общий анализ деятельности предприятия, выработку стратегических решений в бизнесе, а также для подготовки внутренней и внешней отчетности [4].
DSS предоставляет персоналу, не имеющему специальных знаний в области программирования, получить возможность самостоятельно, не прибегая к помощи специалистов информационных служб, составлять запросы к существующим на предприятии источникам информации, просматривать полученные данные с необходимым уровнем детализации или обобщения, производить аналитические действия и формировать печатные отчетные документы.
Эти возможности СППР обусловлены тем, что запросы к источникам данных составляются в привычных для пользователя терминах его бизнеса.
CППР могут классифицироваться по областям их практического применения. По видам профессиональной деятельности различаются СППР для макроэкономики, микроэкономики, управленческого труда, науки, медицины и т. д. Планирование и управление деятельностью организаций - от маленьких фирм до крупнейших корпораций – является одной из наиболее широких сфер приложения СППР.
Основные направления СППР
Рассмотрим подробно две типичные СППР для двух различных областей применения и попробуем выделить в них основные черты. Первая система - это BPCS, предлагаемая компанией SSA. Это решение, позволяющее организовать работу на современном уровне с достижением экономического эффекта от внедрения прикладного пакета СППР. BPCS (Business Planning and Control System) - это система планирования и управления бизнесом, построенная на принципах концепций MRPII и ERP. Более 12000 компаний во всем мире используют систему BPCS на своих предприятиях. BPCS типичный представитель промышленной СППР.
Характерными представителями второго направления являются программные продукты СППР фирмы Business Objects[9,10], которые позволяют создать СППР над источниками данных, отражающими произвольную предметную область. Другими словами, система может использоваться в учреждениях, банках, торговых и производственных предприятиях. Business Objects представляет собой более универсальную и прикладную СППР.
Основными схожими чертами двух систем является то, что BPCS и Business Objects состоят из нескольких сотен программ, работающих с общей базой данных. Программы логически объединены в модули, из которых сформированы три основные подсистемы: производство, логистика (распределение, сбыт/снабжение), финансы. Все модули, а их около 50, системы взаимосвязаны, однако, под конкретные потребности каждого предприятия может быть определен специфический набор модулей. Использование всех модулей системы не является обязательным, основные задачи предприятия могут быть решены набором из 10-12 модулей системы. Кроме этого BPCS и Business Objects являются открытыми системой, поэтому существует возможность дописывания/переписывания под нужды предприятия кода модулей.
Технические требования к вычислительному комплексу определяются ресурсами, необходимыми для нормального функционирования как систем BPCS, так и Business Objects, особенностями предприятия и требованиями по безопасности и надежности системы. Основными параметрами, влияющими на выбор модели сервера, являются:
· набор модулей систем
· наличие удаленных подразделений
· объем хранимой и обрабатываемой информации
· количество одновременно работающих пользователей
Основная особенность промышленных СППР, BPCS не является исключением, это функционирование на платформах класса рабочих станций:
· AS/400
· RISC System
· Digital Alpha
В то время как Business Objects использует платформы, ориентированные на использование Windows(95, NT) и UNIX.
Обе системы могут обеспечить широкий спектр конфигураций Системы Поддержки Принятия Решений - от отдельных рабочих мест СППР и приложений OLAP до централизованной системы с применением технологий Internet/Intranet. С другой стороны, они могут быть использованы для получения информации как из баз данных SQL, в том числе организованных как DataWarehouse, так и быть средством front-end для складов данных, использующих специализированные многомерные СУБД (Arbor Essbase, Oracle Express).
Семантический уровень
Подсистема, которая реализует семантический уровень, позволяет конечным пользователям OLAP формулировать запросы к базе данных, используя свои привычные термины, имеет в BusinessObjects особенности, пока еще редкие в продуктах такого класса. BusinessObjects исходно ориентировал свои продукты как средство построения отчетов и OLAP для реляционных баз данных оперативных приложений, т. е. имеющих такие структуры таблиц и связей, которые оптимизированы на выполнение коротких транзакций. Такие базы, как правило, имеют большое (десятки, сотни) количество таблиц с очень сложной общей структурой связей. Аналитическую информацию здесь часто приходится извлекать из не связанных непосредственно групп таблиц. В BusinessObjects применена схема генерирования скриптов SQL по предварительно описанной программистом модели данных (Universe). Скрипты могут состоять из значительного числа операторов SELECT, которые могут сильно различаться по своей структуре. Полученные выборки синхронизируются между собой по той же модели данных. Эти особенности дают возможность корректно работать по практически произвольным структурам отношений и связей между таблицами, не ограничиваясь простейшими "звездными" или "снежиночными". Вместе с тем, семантический уровень BusinessObjects позволяет работать и с базами данных, организованными как RDBMS DataWarehouse (Informix MetaCube, Sybase IQ и др.), поскольку можно определять специфичное для этой технологии контекстное использование агрегатных таблиц и данных.
Инструментом описания семантики в BusinessObjects является программа Designer. С его помощью программист или администратор, знающий как информация "лежит" в базе, создает каталог терминов конечного пользователя и определяет для каждого термина метод получения данных (фрагменты запроса SQL). Здесь же задаются исходные иерархии измерений и исходные форматы отображения объектов в отчетах. Правила сборки запросов задаются в Designer косвенно описанием структуры связей таблиц, где определяются типы отношений (1:1,1:N, N:N, outer join, shortcut join), параметры связей (фрагменты SQL, которые будут помещаться в условие WHERE), правила разрешения циклов связей (alias таблицы, контексты) и др. Universe могут быть построены по любой базе, доступной через ODBC32 либо напрямую (Teradata, Oracle, Sybase, Informix, Microsoft SQL Server, DB2, CA-Ingres, Red Brick, Rdb ). При прямом доступе используются особенности диалекта SQL конкретной RDBMS. Созданные в Designer Universe используются в клиентских приложениях Reporter, BusinessQuery и WebIntelligence для построения запросов в терминах бизнеса. Для получения информации из серверов OLAP, не использующих SQL (Essbase, Oracle Express), Universe не строятся, поскольку модель данных импортируется из них напрямую клиентским приложением.
Системы управления должны решать как текущие, так и перспективные задачи предприятия. Это означает, что открытая информационная система должна быть адаптирована к постоянно изменяющимся условиям работы предприятия. Это означает, что система должна быть разработана на основе CASE-технологии. Система BPCS полностью разработана в среде CASE при помощи инструментальных средств SSA.
Компания SSA разработала семейство программных продуктов AS/SET, которое позволяет программировать в среде CASE, что значительно сокращает время разработки прикладных программ. AS/SET служит основой для пакетов программ BPCS.
AS/SET содержит все важнейшие компоненты CASE, такие как:
· хранилище прикладных программ, повторно используемых объектов и описаний (repository)
· возможность загрузки описаний существующих файлов и объединения описаний файлов в модель данных
· средства для загрузки уже существующих программ на языке RPG в AS/SET
· проектирование, позволяющее генерировать исходные коды на языках третьего поколения (С++, RPG) для различных платформ
· интерактивные редакторы для экранов, отчетов и логических схем для ускоренного усвоения
· шаблоны программ и графические редакторы для моделирования системы заказчика и быстрой разработки приложений.
·
СASE –технологии
В последнее время все большую популярность приобретают так называемые CASE- технологии (Computer-Aided Software/System Engineering).
CASE - это:
- совокупность методологий анализа, проектирования, разработка и сопровождение сложных систем, поддержанная взаимосвязанных средств автоматизации;
- инструментарий для системных аналитиков, разработчиков, и программистов;
- самостоятельное наукоемкое направление в программотехнике, повлекшее за собой образование мощной CASE-индустрии + наиболее интенсивно развиваемое направление.
Главное достоинство:
- снабжает всех участников проекта (заказчиков, аналитиков, проектировщиков, программистов) общим языком строгим и интуитивно понятным.
Главные цели:
- отделить проектирование системы от ее кодирования и последующих этапов разработки;
- скрыть от разработчиков все детали среды разработки и функционирования системы.
Главные направления применения:
- анализ и проектирование сложных систем;
- перепроектирование бизнес процессов (BPR - business process reengineering).
Основные функции CASE:
- поддержка структурных методологий и, как следствие, возможности применения современных методов системной и программной инженерии;
- возможность создания моделей и прототипов будущей системы, что позволяет на этапе анализа оценить ожидаемый результат;
- возможность построения логического проекта системы, позволяющего поставить задачу для последующих этапов разработки и оценить требуемые ресурсы;
- поддержка коллективной работы и ускорение процесса проектирования и разработки;
- автоматическая генерация документации по проекту;
- улучшение качества создаваемой системы за счет средств автоматического контроля (прежде всего, контроля проекта);
- автоматическая генерация кода (прежде всего схемы БД на основе информационной модели);
- освобождение разработчика от рутинной работы, что позволяет ему целиком сосредоточиться на творческой части разработки;
- поддержка развития и сопровождения разработки.
Основные этапы:
- анализ требований;
- проектирование;
- программирование (кодирование);
- тестирование и отладка;
- эксплуатация и сопровождение.
Анализ требований:
- первая фаза разработки, на которой требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: «Что должна делать будущая система?».
Особенности процесса генерации отчетов в СППР
Формирование запросов в пользовательских терминах, их исполнение, интеграция данных из разных источников, просмотр данных с возможностями детализации и обобщения по иерархиям измерений и построение полноценных отчетов, как экранных так и печатных, должно производиться полностью в рамках одного приложения. BusinessObjects принял это требование как постулат, и поставляемый продукт Reporter с опцией Explorer это обеспечивают. Уровень подготовки специалиста, создающего отчеты, может быть примерно как у среднего пользователя Excel.
Пользователь составляет запрос к источнику данных, используя подготовленный программистом каталог терминов Universe. Reporter автоматически преобразует этот запрос в скрипт SQL, оптимизируя количество и состав операторов SELECT, и производит выборку данных в локальный файл отчета BusinessObjects. В процессе дальнейшей работы выборка может освежаться, пополняться или редуцироваться по желанию пользователя. Данные из выборок отображаются в отчет в виде таблиц, перекрестных таблиц, графиков или отдельных ячеек. Одни и те же данные могут иметь несколько, в том числе и различных, отображений в зависимости от требований к документу. Пользователь может определять производные (вычисляемые) значения в виде контекстно-зависимых или "жестких" переменных и использовать их наравне с основными данными в локальных операциях сортировки, фильтрации, агрегирования, ranking и других основных операциях, наиболее часто используемых при составлении отчетов. Программист может вводить собственные элементарные функции, программируя их, допустим, на С; они очень просто встраиваются в Reporter. Особенностью BusinessObjects является и то, что системы иерархий измерений, по которым пользователь может выполнять операции детализации и обобщения (Drill down/ Drill up), являются гибкими. Пользователь в любой момент может отредактировать или ввести свои собственные иерархии.
Благодаря тому, что пользовательская среда интегрирует формирование запросов с работой пользователя над данными, BusinessObjects, не только по нашему мнению, удалось найти прекрасное решение проблемы прямого доступа к корпоративной информации. Здесь присутствует четкое разделение обязанностей. Задачей программиста является только описание логической модели данных, он не создает выборки «про запас», не пишет специальных приложений для каждого конкретного типа отчета. Пользователь сам определяет ту информацию, которая нужна в данный момент и получает ее непосредственно из того места, где она создается или хранится. При этом информация будет представлена в многомерном виде, пригодном для непосредственного проведения аналитических операций и составления отчета. Полнота описания источника в Universe BusinessObjects и отсутствие промежуточных хранилищ избавляют пользователя от необходимости обращаться к помощи программиста для освежения или реструктурирования выборок данных. Эти черты также дают возможность контроля над производительностью аналитической системы в целом. Например, имея быстрый сервер СУБД и слабую персональную машину, пользователь может строить отчет, спускаясь вниз по иерархиям измерений и фиксируя на каждом шаге фильтры детализации, ограничивая тем самым объем выборки, а значит и уменьшая время локальных вычислений. Или, в обратной ситуации, пользователь может заранее заказать всю информацию, которая может быть понадобится, и затем локально вести обработку. Ввиду того, что документ сохраняется в файл вместе с выборками данных, работа над ним может вестись в режиме off-line при отсутствии связи с источником данных.
Документ BusinessObjects может содержать данные, получаемые одновременно из разных источников. Для этого достаточно определить несколько запросов и, при необходимости, указать по каким полям выборки связаны между собой, задавая тем самым логическую структуру данных отчета.
Хотя метод формирования запросов по каталогам Universe и является основным, поскольку избавляет от необходимости знать что либо о таблицах, связях, SQL и вообще о базах данных, профессионал имеет возможность выбирать информацию непосредственно. Ему доступны SQL, хранимые процедуры (если позволяет сервер СУБД) и персональные данные (текст, DBF, данные из Excel и Lotus 1-2-3). В получаемых таким способом выборках необходимо только указать, какие поля являются измерениями, какие атрибутами, а какие - агрегируемыми значениями.
Для тех пользователей, которые сами не занимаются построением отчетов, существует возможность создания навигационных диалогов при помощи встроенного языка скриптов (аналог языка VB), так и использовать внешнее управление системой, так как она может быть сервером OLE Automation. Последнее свойство может быть использовано для создания комплексных приложений OLAP.
Таким образом, самой минимальной конфигурацией системы BusinessObjects может быть отдельно установленный продукт Reporter. Если отсутствуют заранее подготовленные Universe, то Reporter может применяться для построения простейших табличных и графических отчетов по персональным источникам. Используя созданные в Designer Universe, пользователь получает возможность работы с любыми реляционными базами через семантический уровень. Добавив опцию Explorer, можно будет строить отчеты, содержащие перекрестные таблицы и функциональность Drill. При наличии соответствующих опций можно работать с серверами OLAP Arbor Essbase, Oracle Express и SAP BAPI.
Если на предприятии создается выделенный склад данных, применение BusinessObjects может сделать этот процесс более гладким как на этапе постановки задачи, так и его реализации. Самой сложной задачей, возникающей при построении DataWarehouse, является определение информации, которая должна там храниться. Это можно сделать проанализировав отчеты, наработанные для первичных источников. После создания хранилища можно использовать уже готовые отчеты, просто перенастроив семантический уровень на работу со складом данных.
Интеграция и безопасность
Немаловажной характеристикой, объединяющей BusinessObjects и BPCS является объединение рабочих мест в систему с централизованным администрированием прав пользователей, общими репозиториями Universe и документов. Эта функциональность в BusinessObjects обеспечивается продуктом Supervisor. При помощи Supervisor создается база данных, которая может быть открыта на любом корпоративном SQL сервере, доступном со всех рабочих мест. База будет содержать несколько доменов. Домен Universe позволяет производить дистрибуцию Universe от разработчиков к пользователями. Если пользователь создал по какому-то Universe документ, а потом разработчик или администратор изменили этот Universe в домене, то с этого момента запросы будут проходить по обновленной схеме. Служебный домен Universe Develop используется разработчиком для «обкатки» Universe перед тем, как экспортировать его для общего использования. Домен документов является местом централизованного хранения и дистрибуции разработанных отчетов между пользователями BusinessObjects. Через этот домен пользователь может отправить документ на обработку заданий (обновление отчета, печать, экспорт отчета на Web, рассылка по списку и выполнение скриптов) по расписанию специальным продуктом Document Agent Server (DAS).
Домен безопасности хранит информацию о правах пользователей системы. Начиная с момента подключения рабочего места к домену безопасности, вход в систему будет происходить через процедуру аутентификации пользователя. Документы и Universe, созданные в этом режиме становятся недоступными при отключении от домена или при отсутствии разрешения администратора на работу в режиме off-line данному пользователю. Администратор может определять время работы пользователя, его права по доступу к данным и функциональным возможностям системы. При назначении прав доступа к данным администратор может ограничить конкретного пользователя как по доступу к отдельным объектам каталогов Universe, так и по значениям данных путем прописывания соответствующих фрагментов запросов SQL в условиях WHERE. Доступная функциональность задается как назначением видимости органов управления приложением, так и запрещением отдельных операций (вплоть до копирования в Clipboard). Все операции администрирования могут производиться с одного рабочего места администратора Supervisor. Одновременно могут администрироваться более 10.000 пользователей и этому есть живые примеры (Shell, Defense Medical Logistics (US Department of Defense) and, just recently, Lucent).
Доступ из Internet/Intranet
Продукт BusinessObjects WebIntelligence позволяет обращаться к корпоративной информации, пользуясь стандартным Web браузером с любой платформы (Windows, Mac, UNIX), имеющим встроенную виртуальную машину Java. Нетехнический пользователь может строить и просматривать отчеты, задавая произвольные запросы к базам данных опять же в терминах своего бизнеса. WebIntelligence использует те же Universe, что и другие средства BusinessObjects. Как и в предыдущих продуктах, пользователю WebIntelligence нет необходимости привлекать специалистов для проведения каких либо операций по конструированию выборок, промежуточных многомерных баз и т. д. Сохраняется возможность работы с репозиториями и способы администрирования.
В WebIntelligence реализована схема тонкого клиента, работающего с удаленным сервером приложений. Средством формулирования запросов и работы с отчетом является аплет Java, код которого автоматически передается в браузер в момент первого обращения к серверу приложений. Обновления кода происходят в дальнейшем только при появлении его новых версий. Формирование выборок и построение документа производится на сервере приложений WebIntelligence, который передает изображение документа клиенту в виде страниц HTML. Сервер WebIntelligence использует стандартные средства доступа к корпоративным базам, такие как SQL*Net for Oracle, Open Client for SQL Server или ODBC.
Такой подход был применен BusinessObjects потому, что, во-первых, в настоящий момент только таким путем можно обеспечить многоплатформность и ликвидировать затраты на техническую поддержку. Альтернативные подходы либо не обеспечивают многоплатформность (ActiveX пока существует только для Windows), либо требуют переустановки клиентских продуктов при выходе новых версий (технология Plug-In). Во-вторых, наибольшую вычислительную нагрузку можно перенести на сервер, оставив на клиентском месте только органы управления.
Распределенная объектная технология, на которой базируется WebIntelligence, придает исключительную гибкость и возможность расширяемости потому, что компоненты сервера WebIntelligence могут работать как на отдельной машине, так и быть распределенными по нескольким системам. В последнем случае обеспечивается динамическое распределение нагрузки по компонентам как при выполнении задач, так и при отказах отдельных серверов. Распределенная компонентная архитектура DCA WebIntelligence реализована на CORBA - совместимой технологии ORB (object request broker), лицензированной у фирмы Visigenic Software.
Внедрение систем
Как показали результаты анализа внедрение систем BPCS и BusinessObjects можно разбить на 5 фаз:
Фаза1 Определение проекта
Анализ
Разработка плана внедрения
Выбор проектной команды
Проведение курса MRPII
Подготовка меморандума проекта
Фаза2 Подготовка внедрения
Инсталляция BPCS
Курс обучения «Концепции и применения»
Анализ текущих операций
Подготовка моделирования работы предприятия в системе BPCS и BusinessObjects
Курс обучения по подсистемам (Финансы, Логистика, Производство)
Проведение моделирования
Техническое обучение
Подготовка схемы внедрения системы
Фаза3 Разработка и утверждение
Разработка возможных изменений
Обучение конечных пользователей
Фаза4 Запуск системы
Ввод исходных данных
Переход к работе в новой системе
Фаза5 Работа в новой системе
Уточнение работы новой системы
Мониторинг результатов работы системы
Заключение
Предлагаемый текст представляет собой описание текущего состояния исследований по рассматриваемой проблеме. Решаемая задача на данном этапе представляется плохо формализуемой. Одной из ближайших целей исследований является попытка формализации задачи на основе пилотного изучения некоторых образцов программных продуктов и примеров спецификации класса принимаемых решений.
Литература
1. , , Голосов реляционных СУБД при разработке информационных систем. Препринт, М.: ВНИИСИ, 1989.
2. Бритков поддержки и актуализации данных в информационных системах, Межотраслевая информационная служба, Научно-методический журнал, 1997, вып. 3, с. 41-48.
3. , Бритков поддержки принятия решений в нештатных ситуациях с использованием современной информационной технологии.// Системные исследования. Методологические проблемы. Ежегодник 1996. Москва, Эдиториал УРСС, 1996, с. 179-190.
4. , Юрченко компьютерного моделирования, Международный научно-исследовательский институт проблем управления, Москва, 1990.
5. , Попов бизнеса, М.: Финансы и Статистика, 1997.
6. Приобретение знаний, под ред. М.: Мир,1990.
7. Gelovani V. A., Britkov V. B., Yurchenko V. V. An Interactive Modelling System for Analysis of Alternative Decisions //Decision Support Systems: Issues and Challenges. IIASA Proceedings, N 11, 1980.
8. .Jaber A., Guarnieri F., Wybo J. L. A System of Intelligent Software Agents to Favour the Co-operation between Emergency Decision Support Systems. In.: The International Emergency Management Society Conference "Disaster and Emergency Management: International Challenges for the Next Decade", Washington, DC, Edited by J. Harrald and G. Shaw. 1998, Washington. 1998. pp.515-526.
9. http://www.
9. http://www. *****
