| |||
Реферат: Создание систем поддержки принятия решений
Введение 3 ВВЕДЕНИЕ В той или иной степени Системы Поддержки Принятия Решений (СППР)
присутствуют в любой информационной системе (ИС). Поэтому, осознанно или
нет, к задаче создания системы поддержки принятия решений организации
приступают сразу после приобретения вычислительной техники и установки
программного обеспечения. По мере развития бизнеса, упорядочения структуры
организации и налаживания межкорпоративных связей, проблема разработки и
внедрения СППР становится особенно актуальной. Одним из подходов к созданию
таких систем стало использование хранилищ данных. В настоящей статье
рассматриваются этапы и методики проведения подобных работ на опыте и с
применением методологии компании Price Waterhouse, которая на сегодня
выполнила 40 крупномасштабных проектов по созданию корпоративных Хранилищ СППР можно, в зависимости от данных, c которыми они работают, разделить на оперативные, предназначенные для немедленного реагирования на текущую ситуацию, и стратегические - основанные на анализе большого количества информации из разных источников с привлечением сведений, содержащихся в системах, аккумулирующих опыт решения проблем. СППР первого типа получили название Информационных Систем Руководства - отчеты, как правило, базируются на стандартных для организации запросах; число последних относительно невелико; - ИСР представляет отчеты в максимально удобном виде, включающем, наряду с таблицами, деловую графику, мультимедийные возможности и т. п.; - как правило, ИСР ориентированы на конкретный вертикальный рынок, например финансы, маркетинг, управление ресурсами. СППР второго типа предполагают достаточно глубокую проработку данных, специально преобразованных так, чтобы их было удобно использовать в ходе процесса принятия решений. Неотъемлемым компонентом СППР этого уровня являются правила принятия решений, которые на основе агрегированных данных подсказывают менеджерскому составу выводы и придают системе черты искусственного интеллекта. Такого рода системы создаются только в том случае, если структура бизнеса уже достаточно определена и имеются основания для обобщения и анализа не только данных, но и процессов их обработки. Если ИСР есть не что иное как развитие системы оперативного управления производственными процессами, то СППР в современном понимании - это механизм развития бизнеса, который включает в себя некоторую часть управляющей информационной системы, обширную систему внешних связей предприятия, а также технологические и маркетинговые процессы развития производства. 1. Зарождение концепции хранилища данных Ясно, что чем больше информации вовлечено в процесс принятия решений,
тем более обоснованное решение может быть принято. Информация, на основе
которой принимается решение, должна быть достоверной, полной,
непротиворечивой и адекватной. Поэтому при проектировании СППР возникает
вопрос о том, на основе каких данных эти системы будут работать. В ИСР
качество оперативных решений обеспечивается тем, что данные выбираются
непосредственно из информационной системы управления предприятием (или из По мере роста и развития ИСР, а также совершенствования алгоритмов принятия решений на основе агрегированных данных, системы принятия решений столкнулись с проблемами, вызванными необходимостью обеспечить растущие потребности бизнеса. В ИСР накопился объем данных, замедляющий процесс построения отчетов настолько, что менеджерский состав не успевал готовить на их основе соответствующие решения. Кроме того, с развитием межкорпоративных связей потребовалось вовлекать в процесс анализа данные из внешних источников, не связанных напрямую с производственными процессами и потому не входящих в систему управления предприятием. В СППР второго типа традиционная технология подготовки интегрированной
информации на основе запросов и отчетов стала неэффективной из-за резкого
увеличения количества и разнообразия исходных данных. Это стало сильно
задерживать менеджмент, для которого требовалось быстро принимать решения. Решение было найдено и сформулировано в виде концепции Хранилища Данных Этот подход потребовал новых технологических решений, к созданию
которых несколько лет назад приступили основные производители промышленных Ограниченный объем статьи не позволил рассмотреть все аспекты 2. Технология разработки и внедрения Хранилища Данных 2.1. Этапы проекта Первой фазой проекта разработки ХД является бизнес-анализ процессов и данных предприятия. В России, несмотря на широкое распространение CASE- технологии, к бизнес-анализу и проектированию данных на концептуальном уровне не всегда относятся достаточно серьезно. Между тем относительно СППР на основе ХД можно с уверенностью утверждать, что ее разработка без подобного анализа заранее обречена на неудачу. Без ясного понимания разработчиками целей бизнеса, способов их достижения, возникающих при этом проблем и методов их решения, ресурсы, необходимые для разработки ХД, будут потрачены зря. Самым критичным из ресурсов сейчас является время, и тот, кто начал разработку СППР, не определив заранее, кто, когда, зачем и как будет принимать решения, какое влияние то или иное решение оказывает на бизнес, какие решения отнести к оперативным, а какие к стратегическим и т. д., обрекает себя на неизбежное отставание в конкурентной борьбе. Основное назначение модели предприятия - определение и формализация данных, действительно необходимых в процессе принятия решения. Известно два подхода к бизнес-анализу. Первый ориентируется на описание бизнес- процессов, протекающих на предприятии, которое моделируется набором взаимосвязанных функциональных элементов. Поскольку эти процессы, как правило, хорошо известны, на первый взгляд кажется, что это самый естественный и быстрый путь бизнес-анализа. Действительно, если бизнес стабилен и внешние факторы не играют в нем решающей роли либо также стабильны, этот путь может оказаться наиболее эффективным. Второй подход основан на первичном анализе бизнес-событий. При проектировании СППР на основе ХД именно он обеспечивает наибольшую эффективность: - позволяет гибко модифицировать бизнес-процессы, ставя их в зависимость от бизнес-событий; - интегрирует данные, которые при анализе бизнес-процессов остаются скрытыми в алгоритмах обработки данных; - объединяет управляющие и информационные потоки; - наглядно показывает, какая именно информация нужна при обработке бизнес-события и в каком виде она представляется. Иными словами, бизнес-событие является более устойчивым и более тесно связанным с информационными и управляющими потоками понятием, чем бизнес- процесс. Через анализ бизнес-событий необходимо перейти к анализу данных, используемых предприятием. При этом должна быть собрана информация об используемых внешних данных и их источниках; о форматах данных, периодичности и форме их поступления; о внутренних информационных системах предприятия, их функциях и алгоритмах обработки данных, используемых при наступлении бизнес-событий. Такой анализ, как правило, производится при проектировании любой информационной системы. Особенность анализа данных при проектировании СППР на основе ИХ состоит в необходимости создания моделей представления информации. То, что в транзакционных системах является вторичным понятием, а именно состав и форма отображаемых данных, в СППР приобретает особую важность, так как нужно выявить все без исключения признаки, требуемые для менеджерского состава. При проектировании транзакционной системы обычно строго выдерживается
последовательность процессов: бизнес-анализ, концептуальная модель данных,
физическая модель данных, структура интерфейса и т. п. Возврат на
предыдущий уровень происходит редко и считается отклонением от нормального
хода выполнения проекта. В случае СППР на основе ХД нормальным считается
итерационный, а иногда и параллельный, характер моделирования, при котором
возврат на предыдущую стадию - обычное явление. Это связано с
необходимостью выделения всех требуемых данных для произвольных запросов В ходе анализа бизнес-событий необходимо также сформировать схему взаимодействия между транзакционной и аналитической системами на предприятии. Помимо того, что транзакционная система зачастую является важнейшим источником данных для хранилища, желательно задействовать один и тот же пользовательский интерфейс в ИСР и СППР. Подходы к совместному использованию этих систем определяются именно на данной фазе выполнения проекта. Итак, по результатам анализа бизнес-процессов и структур данных предприятия отбирается действительно значимая для бизнеса информация с учетом неопределенности будущих запросов. Следующий шаг связан с пониманием того, в каком виде и на каких аппаратных и программных платформах размещать структуру данных СППР на основе ХД. 2.2. Выбор модели данных Хранилища В самом простом варианте для Хранилищ Данных используется та модель
данных, которая лежит в основе транзакционной системы. Если, как это часто
бывает, транзакционная система функционирует на реляционной СУБД (Oracle, Однако практика принятия решений показала, что существует зависимость
между частотой запросов и степенью агрегированности данных, с которыми
запросы оперируют, а именно чем более агрегированными являются данные, тем
чаще запрос выполняется. Другими словами, круг пользователей, работающих с
обобщенными данными, шире, чем тот, для которого нужны детальные данные. OLAP-системы построены на двух базовых принципах: - все данные, необходимые для принятия решений, предварительно агрегированы на всех соответствующих уровнях и организованы так, чтобы обеспечить максимально быстрый доступ к ним; - язык манипулирования данными основан на использовании бизнес-понятий. В основе OLAP лежит понятие гиперкуба, или многомерного куба данных, в ячейках которого хранятся анализируемые (числовые) данные, например объемы продаж. Измерения представляют собой совокупности значений других данных, скажем названий товаров и названий месяцев года. В простейшем случае двумерного куба (квадрата) мы получаем таблицу, показывающую значения уровней продаж по товарам и месяцам. Дальнейшее усложнение модели данных может идти по нескольким направлениям: - увеличение числа измерений - данные о продажах не только по месяцам и товарам, но и по регионам. В этом случае куб становится трехмерным; - усложнение содержимого ячейки - например нас может интересовать не только уровень продаж, но и, скажем, чистая прибыль или остаток на складе. В этом случае в ячейке будет несколько значений; - введение иерархии в пределах одного измерения - общее понятие «Время» естественным образом связано с иерархией значений: год состоит из кварталов, квартал из месяцев и т. д. Речь пока идет не о физической структуре хранения, а лишь о логической модели данных. Другими словами, определяется лишь пользовательский интерфейс модели данных. В рамках этого интерфейса вводятся следующие базовые операции: - поворот; - проекция. При проекции значения в ячейках, лежащих на оси проекции, суммируются по некоторому предопределенному закону; - раскрытие (drill-down). Одно из значений измерения заменяется совокупностью значений из следующего уровня иерархии измерения; соответственно заменяются значения в ячейках гиперкуба; - свертка (roll-up/drill-up). Операция, обратная раскрытию; - сечение (slice-and-dice). В зависимости от ответа на вопрос, существует ли гиперкуб как отдельная
физическая структура или лишь как виртуальная модель данных, различают
системы MOLAP (Multidimensional OLAP) и ROLAP (Relational OLAP). В первых
гиперкуб реализуется как отдельная база данных специальной нереляционной
структуры, обеспечивающая максимально эффективный по скорости доступ к
данным, но требующая дополнительного ресурса памяти. MOLAP-системы весьма
чувствительны к объемам хранимых данных. Поэтому данные из хранилища
сначала помещаются в специальную многомерную базу (Multidimensional Data Одним из первых производителей таких систем стала компания Arbor Для систем ROLAP гиперкуб - это лишь пользовательский интерфейс,
который эмулируется на обычной реляционной СУБД. В этой структуре можно
хранить очень большие объемы данных, однако ее недостаток заключается в
низкой и неодинаковой эффективности OLAP - операций. Опыт эксплуатации Некоторые поставщики программных продуктов (Sybase - Sybase IQ, При определении программно-технологической архитектуры Хранилища следует иметь в виду, что система принятия решения, на какие бы визуальные средства представления она ни опиралась, должна предоставить пользователю возможность детализации информации. Руководитель предприятия, получив интегрированное представление данных и/или выводы, сделанные на его основе, может затребовать более детальные сведения, уточняющие источник данных или причины выводов. С точки зрения проектировщика СППР, это означает, что необходимо обеспечить взаимодействие СППР не только с Хранилищем Данных, но и в некоторых случаях с транзакционной системой. 2.3. Выбор структуры Хранилища Данных Несколько лет назад для Хранилищ Данных было предложено использовать схемы данных, получившие названия "звезда" и "снежинка". Суть технологии проектирования этих схем заключается в выделении из общего объема информации собственно анализируемых данных (или фактов) и вспомогательных данных (называемых измерениями). Необходимо, однако, отдавать себе отчет в том, что это приводит к дублированию данных в Хранилище, снижению гибкости структуры и увеличению времени загрузки. Все это - плата за эффективный и удобный доступ к данным, необходимый в СППР. Несмотря на то что предсказать, какую именно информацию и в каком виде
захочет получить пользователь, работая с СППР, практически невозможно,
измерения, по которым проводится анализ, достаточно стабильны. В процессе
подготовки того или иного решения пользователь анализирует срез фактов по
одному или нескольким измерениям. Анализ информации, исходя из понятий
измерений и фактов, иногда называют многомерным моделированием данных Поскольку в Хранилищах Данных, наряду с детальными, должны храниться и агрегированные данные, в случае "снежинки" или "звезды" появляются таблицы агрегированных фактов (агрегатов). Подобно обычным фактам, агрегаты могут иметь измерения. Кроме того, они должны быть связаны с детальными фактами для обеспечения возможной детализации. На практике Хранилища часто включают в себя несколько таблиц фактов, связанных между собой измерениями, которые таким образом разделяются между несколькими таблицами фактов. Такая схема носит название "расширенная снежинка", и именно она, как правило, встречается в Хранилищах Данных. Для достижения наивысшей производительности иногда используют подход, при котором каждая "звезда" располагается в отдельной базе данных или на отдельном сервере. Хотя такой подход приводит к увеличению размера дискового пространства за счет дублирования разделенных измерений, он может оказаться весьма полезным при организации Витрин Данных. При проектировании структуры хранилища часто возникает желание
использовать как можно больше агрегатов и за счет этого повысить
производительность системы. Нетрудно подсчитать, что для модели "звезда" с 2.4. Витрины Данных Идея Витрины Данных (Data Mart) возникла несколько лет назад, когда стало очевидно, что разработка корпоративного хранилища - долгий и дорогостоящий процесс. Это обусловлено как организационными, так и техническими причинами: - информационная структура реальной компании, как правило, очень сложна, и руководство зачастую плохо понимает суть происходящих в компании бизнес-процессов; - технология принятия решений ориентирована на существующие технические возможности и с трудом поддается изменениям; - может возникнуть необходимость в частичном изменении организационной структуры компании; - требуются значительные инвестиции до того, как проект начнет окупаться; - как правило, требуется значительная модификация существующей технической базы; - освоение новых технологий и программных продуктов специалистами компании может потребовать много времени; - на этапе разработки бывает трудно наладить взаимодействие между разработчиками и будущими пользователями Хранилища. В совокупности это приводит к тому, что разработка и внедрение
корпоративного хранилища требуют значительных усилий по анализу
деятельности компании и переориентации ее на новые технологии. Витрины Сейчас под Витриной Данных понимается специализированное Хранилище,
обслуживающее одно из направлений деятельности компании, например учет
запасов или маркетинг. Важно, что происходящие здесь бизнес-процессы, во-
первых, относительно изучены и, во-вторых, не столь сложны, как процессы в
масштабах всей компании. Количество сотрудников, вовлеченных в конкретную
деятельность, также невелико (рекомендуется, чтобы Витрина обслуживала не
более 10-15 человек). При этих условиях удается с использованием
современных технологий развернуть Витрину подразделения за 3-4 месяца. Первые же попытки внедрения Витрин Данных оказались настолько
успешными, что вокруг новой технологии начался настоящий бум. Предлагалось
вообще отказаться от реализации корпоративного Хранилища и заменить его
совокупностью Витрин Данных. Однако вскоре выяснилось, что с ростом числа Фактическим стандартом структуры данных при разработке Витрины является 2.5. Хранилище Метаданных (Репозитарий) Принципиальное отличие Системы Поддержки Принятия Решений на основе Широко известны Репозитарии, входящие в состав популярных CASE-средств Разработка системы управления метаданными сходна с разработкой распределенной транзакционной системы. При ее создании необходимо решать следующие задачи: - анализ процессов возникновения, изменения и использования метаданных; - проектирование структуры хранения метаданных (например, в составе реляционной базы данных); - организация прав доступа к метаданным; - блокировка и разрешение конфликтов при совместном использовании метаданных (что очень часто возникает при изменении общих бизнес- понятий в рамках структурного подразделения); - разделение метаданных между Витринами Данных; - согласование метаданных ХД с Репозиториями CASE-средств, применяемых при проектировании и разработке Хранилищ; - реализации пользовательского интерфейса с Репозитарием. Опыт реализации систем управления метаданными показывает, что основная
трудность состоит не в программной реализации, а в определении содержания
конкретных метаданных и методики работы с ними, в практическом внедрении Поскольку большинство CASE-средств использует различные форматы
метаданных, поставщики систем управления метаданными выработали стандарт
обмена MDIS, обеспечивающий возможность интеграции CASE-средств в СППР на
основе ХД. К сожалению, не все предлагаемые сегодня на российском рынке
продукты соответствуют этому стандарту, поэтому преобразование форматов
метаданных представляет собой достаточно сложный процесс, упростить который
призваны специализированные программные продукты, в том числе, например,
средства фирмы Evolutionary Technologies International или Prism Solutions Когда структура метаданных разработана и система управления ими спроектирована, решается задача заполнения и обновления данных в ХД. 2.6. Загрузка Хранилища Какие данные должны быть помещены в Хранилище? Как найти и извлечь эти данные? Как обеспечить корректность данных в Хранилище? Подобные вопросы являются ключевыми при проектировании Хранилищ. В сущности, определяя, чем заполняется Хранилище, мы неявно определяем спектр задач, которые будут решаться с его помощью, и круг потенциальных пользователей. При описании технологии заполнения Хранилища будем различать три
взаимосвязанные задачи: Сбор Данных (Data Acquisition), Очистка Данных Под Сбором Данных будем понимать процесс, который состоит в организации
передачи данных из внешних источников в Хранилище. Лишь некоторые аспекты
этого процесса полностью или частично автоматизированы в имеющихся
продуктах. Прежде всего, это относится к интерфейсам с существующими БД. Второй аспект процесса сбора данных, который автоматизирован в
некоторых продуктах, - это организация процесса пополнения Хранилища. В том
же InfoPump, например, имеется возможность строить расписание пополнения Под очисткой данных обычно понимается процесс модификации данных по ходу заполнения Хранилища: исключение нежелательных дубликатов, восстановление пропущенных данных, приведение данных к единому формату, удаление нежелательных символов (например, управляющих) и унификация типов данных, проверка на целостность. Практически все продукты располагают тем или иным набором средств очистки данных и соответствующими средствами диагностики. При заполнении Хранилища агрегированными данными мы должны обеспечить
выборку данных из транзакционной базы данных и других источников в
соответствии с метаданными, поскольку агрегирование происходит в терминах
бизнес-понятий. Так, например, агрегированная величина "объем продаж
продукта Х в регионе Y за последний квартал" содержит понятия "продукт" и Простейшей архитектурой системы на основе ХД является архитектура
клиент-сервер. Традиционно само хранилище размещается на сервере (или на
серверах), а анализ данных выполняется на клиентах. Некоторое усложнение в
эту схему вносят Витрины Данных. Они также размещаются на серверах, но,
учитывая взаимодействия между Витринами, приходится вводить так называемые
переходники (Hub Servers), через которые идет обмен данными между 2.7. Анализ данных: OLAP Предположим теперь, что в общем случае имеется корпоративное ХД и ряд Наряду с мощными серверами многомерных баз данных и ROLAP-серверами на
рынке предлагаются клиентские OLAP-серверы, предназаначенные, главным
образом, для работы с небольшими объемами данных и ориентированные на
индивидуального пользователя. Подобные системы были названы настольными,
или DOLAP-серверами (Desktop OLAP). В этом направлении работают фирмы Лидером пока считается компания Cognos, поставляющая продукты Стоит отметить, что все эти фирмы объединяет стремление включить в свои
продукты компоненты, предназначенные для Интеллектуального Анализа Данных Необходимо также упомянуть о новом направлении развития архитектур систем клиент-сервер, называемом трехуровневой архитектурой клиент-агент- сервер. Применительно к СППР традиционная двухуровневая архитектура подразумевает, что Хранилище Данных или Витрина Данных размещаются на сервере, а аналитическая обработка и пользовательские интерфейсы поддерживаются клиентом. Можно привести некоторые условия, при которых двухуровневая архитектура работает эффективно: - объем данных, пересылаемых между клиентом и сервером, не очень велик; - большая часть вычислений может быть выполнена заранее; - круг пользователей-клиентов четко определен, так что сервер обслуживает умеренное число запросов в единицу времени; - нет необходимости поддерживать разделение данных между клиентами (клиенты изолированы друг от друга); - приложения не требуют постоянных модификаций и усовершенствований. Практика показывает, что аналитическая обработка, несмотря на
подготовленность агрегированных данных в Хранилище или Витрине, может
оказаться не такой простой задачей. Например, если требуется
проанализировать отношение прибыли к расходам, возможно, эту задачу
придется решать динамически, поскольку именно такого отношения в Хранилище
может и не быть (при том, что прибыль и расходы, скорее всего, там
присутствуют). Выполнение подобных вычислений на клиенте перегружает
систему, увеличивает время отклика, требует повторных вычислений при
повторении запроса или хранения однажды вычисленных значений в памяти
клиента. В этом случае принято говорить, что клиент становится "тяжелым" В трехуровневых архитектурах между клиентом и сервером (который теперь
называется корпоративным сервером) помещается еще одни сервер, называемый
сервером приложений. Обязанностью корпоративного сервера является работа с
корпоративными данными, например с Хранилищем Данных: организация доступа к Для данной архитектуры в примере с поиском отношения прибыль/расходы
вычисление этого отношения следовало бы выполнять на сервере приложений. В Логическое разделение системы на три уровня не означает наличия трех физических уровней обработки. Теоретически все три уровня могут быть реализованы на одной машине. Наличие трех логических уровней означает, во- первых, строгое разделение обязанностей между уровнями и, во-вторых, регламентацию связей между ними. Так, например, клиент не может непосредственно обратиться к корпоративному серверу. 3. Интеллектуальный анализ данных Интеллектуальный анализ данных (ИАД) обычно определяют как метод
поддержки принятия решений, основанный на анализе зависимостей между
данными. В рамках такой общей формулировки обычный анализ отчетов,
построенных по базе данных, также может рассматриваться как разновидность Существует два подхода. В первом случае пользователь сам выдвигает гипотезы относительно зависимостей между данными. Фактически традиционные технологии анализа развивали именно этот подход. Действительно, гипотеза приводила к построению отчета, анализ отчета к выдвижению новой гипотезы и т. д. Это справедливо и в том случае, когда пользователь применяет такие развитые средства, как OLAP, поскольку процесс поиска по-прежнему полностью контролируется человеком. Во многих системах ИАД в этом процессе автоматизирована проверка достоверности гипотез, что позволяет оценить вероятность тех или иных зависимостей в базе данных. Типичным примером может служить, такой вывод: вероятность того, что рост продаж продукта А обусловлен ростом продаж продукта В, составляет 0,75. Второй подход основывается на том, что зависимости между данными ищутся
автоматически. Количество продуктов, выполняющих автоматический поиск
зависимостей, говорит о растущем интересе производителей и потребителей к
системам именно такого типа. Сообщается о резком росте прибылей клиентов за
счет верно найденной, заранее неизвестной зависимости. Упоминается пример
сети британских универсамов, где ИАД применялся при анализе убытков от
хищений товаров в торговых залах. Было обнаружено, что к наибольшим убыткам
приводят хищения мелких "сопутствующих" товаров: ручек, батареек и т. п. Сегодня количество фирм, предлагающих продукты ИАД, исчисляется десятками, однако, не рассматривая их подробно, приведем лишь классификацию процессов ИАД, применяющихся на практике. Процессы ИАД подразделяются на три большие группы: поиск зависимостей В системах ИАД применяется чрезвычайно широкий спектр математических,
логических и статистических методов: от анализа деревьев решений (Business Необходимо также упомянуть об интеграции ИАД в информационные системы. Заключение Создание СППР на основе хранилищ данных - сложный, но обозримый
процесс, требующий знания бизнеса, программно-технического инструментария и
опыта выполнения крупных проектов. Вместе с тем внедрение подобных систем
может дать преимущества в бизнесе, которые будут тем ощутимее, чем раньше
организация начнет создание СППР. По прогнозам консалтинговой фирмы Gartner Значимость информационных систем подобного уровня признается и представителями большинства российских компаний. Однако в силу ряда причин, инициативные или заказные работы ведутся зачастую достаточно бессистемно, в основном в двух направлениях: - закупка и тестирование разнообразных продуктов, применяемых при создании СППР и ХД (к сожалению, большинство из них плохо сопрягаются друг с другом, из-за чего создается ложное впечатление "неподъемности" проблемы); - решение частного вопроса о повышении производительности отчетных систем путем локального перепроектирования структуры хранения или перехода на более современные и сложные программные средства. Список литературы 1. Система поддержки принятия решений в человеко-машинных системах
управления. Труды Института проблем управления РАН им. В.А.Трапезникова. 2. Арлазаров В.Л., Журавлев Ю.И., Ларичев О.И., Лохин В.М., Макаров 3. Валькман Ю.Р. Интеллектуальные технологии исследовательского проектирования. -Киев.: Port-Royal. -1998. 4. Комарцова Л.Г. Оптимизация вычислительной системы на ее имитационной
модели. // Вестник МГТУ им. Н.Э.Баумана. - сер. "Приборостроение". -1999. 5. Литвак Б.Г. Экспертные технологии управления. М.: Дело, 2004г. 6. Трахтенгеру Э.А. Компьютерная поддержка принятия решений. – М.: 7. Чекинов Г.П., Куляница А.Л., Бондаренко В.В. Применение ситуационного управления в информационной поддержке принятия решений при проектировании организационно-технических систем // Информационные технологии в проектировании и производстве, № 2, 2003.
|
|