Проектирование систем поддержки принятия решений

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

 

 

 

2.2. Принципы построения систем поддержки принятия решений

Выделяют  следующие принципы построения СППР.

• интерактивность;

• использование  СУБД различных типов;

• интеллектуализация.

Основным  принципом построения СППР является обеспечение их интерактивности, так как процесс принятия сложных решений не может быть выполнен на ЭВМ полностью автоматически и участие руководителя в этом процессе обязательно. Средства диалога в СППР строятся на базе современных требований и средств диалоговых систем и зависят от таких факторов, как эффективные языки действия, языки представления результатов и знания об общении "пользовательсистема". Языки действия должны задавать средства взаимодействия руководителя с системой (меню, команды, естественный предметный язык). Языки представления должны обеспечить пользователю возможность получать и видеть результаты в форме:

• деловых  таблиц;

• отчетов;

• графиков;

• диаграмм;

• чертежей и т. п.

Современным СППР необходимы различные интерактивные  средства манипулирования данными, множественного доступа к данным на пользовательском уровне. Поэтому в них широко используются системы управления базами данных  различных типов (реляционные, сетевые и др.)[5].

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

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

2.3. Эксплуатационные требования к системе поддержки принятия решений с позиции пользователя

Первые  три из указанных ниже требований имеют отношение к типу задачи, решаемой лицом, принимающим решение. Остальные – связаны с типом  оказываемой ему помощи:

• СППР должны осуществлять помощь в принятии решений и быть особенно эффективными при решении неструктурированных и плохо структурированных задач. Имеются в виду задачи, при решении которых использование СЭОД, ИСУ и моделей исследования операций обычно не давало результатов.
• СППР должны осуществлять помощь в принятии решений управленцами всех уровней, а также при координации решений, требующих участия нескольких уровней управления.
• СППР должны осуществлять помощь в принятии как индивидуальных, так и коллективных решений. Здесь имеются в виду решения, ответственность в которых разделена между несколькими руководителями или внутри группы работников.
• СППР должны осуществлять помощь на всех стадиях процесса принятия решений. Как будет показано ниже, если на стадиях изучения проблемы и сбора данных СППР оказывает лишь дополнительную помощь (главный вклад вносит использование ИСУ), то на всех последующих стадиях (кроме стадии принятия решения) помощь, оказываемая СППР, является превалирующей.
• СППР, оказывая помощь при принятии различных решений, не может зависеть ни от одного из них.
• Использовать СППР должно быть легко. Это обеспечивается высокой адаптивностью системы по отношению к виду задач, особенностям организационного окружения и пользователя, а также дружественным интерфейсом.

2.4. Задачи систем поддержки принятия решений

Тем самым, чтобы система поддержки принятия решений стала надежной опорой для  руководителя, она должна:

• обеспечивать возможность работы руководителей напрямую с информацией без любых посредников, т. е. без привлечения ИТ-службы и других подразделений, которые смогут перестать заниматься бесконечной подготовкой отчетов для руководства и сконцентрироваться на более качественном решении операционных задач;
• при планировании предоставлять возможность оперативного моделирования и анализа развития ситуации по принципу «что, если» и разработки программы действий для каждого варианта;
• позволять использовать ранее накопленные в компании опыт и знания. Например, давать возможность руководителю посмотреть, возникала ли аналогичная ситуация в прошлом, какие тогда были приняты решения и к чему они привели;
• обеспечивать возможность анализа данных, получения отчетности в различных разрезах по всем аспектам деятельности компании — для мониторинга и контроля исполнения намеченных планов и их последующей коррекции;
• опираться в своей работе на данные из различных источников, в том числе — из транзакционных информационных систем, где отражаются сведения об основных аспектах производственной и финансовой деятельности компании, и работать с неструктурированными данными;
• решать определенные математические задачи, связанные с расчетом заданных показателей и алгоритмов;
• быть гибкой и легко адаптируемой к особенностям деятельности компании, поддерживать эволюционное использование и легко модифицироваться в соответствии с изменившимися требованиями со стороны бизнеса;
• предоставлять информацию в понятном и удобном для восприятия виде, включая различные таблицы, графики, мультимедийные средства;
• поддерживать индивидуальный и групповой режимы работы.

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

 

 

 

 

 

Глава 3. Анализ бизнес-процессов деятельности рекламного агентства

3.1 Функциональная модель деятельности рекламного агентства в графической нотации IDEF0

В программной  среде RamusEducational Version: 1.1.1 была разработана  функциональная модель деятельности выбранной организации в графической нотации IDEF0.

Была построена  контекстной диаграмме А-0(диаграмма верхнего уровня) .На ней показана деятельность рекламного агентства(Рис 7.).

Рис. 7. Контекстная диаграмма деятельности рекламного агентства(A-0)

На рис.8 представлена диаграмма декомпозиции (А0), на которой деятельность системы декомпозируется на следующие процессы:

1. формирование заказа;
2. планирование рекламной компании;
3. создание рекламы;
4. размещение в СМИ.

Рис. 8. Диаграмма декомпозиции А0 («as is»)

В ходе анализа  построенной диаграммы декомпозиции «as is» были выявлены достаточно существенные недостатки данной модели, а именно:

• не осуществлена возможность исследования данных отчетной документации после размещения рекламы;
• не предусмотрены действия в случае непринятия рекламной продукции в средствах массовой информации (реклама окажется некачественной или формат рекламы не будет подходить под данный вид СМИ).

На рис. 9 представлена диаграмма декомпозицииA0 «to be». В ней учтены все недоработки модели «as is».

Предусмотренные новшества должны улучшить процесс  организации деятельности рекламного агентства.

Рис. 9. Диаграмма декомпозиции А0 («to be»)

На следующем  уровне был декомпозирован блок «Создание  рекламы».

Диаграмма «as is» представлена на рис. 10. Была построена диаграмма «as is» и модель «to be», в которой была добавлена такая новая функция, как:

• исправление орфографии или оформления текстов, надписей и рисунков на рекламной продукции

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

Диаграмма «to be», в которой выполнена значительное обновление процесса создания рекламы, представлена на рис. 12.

 

 

 

 

 

Рис. 10. Диаграмма А3 («as is»)

 

Рис. 11. Диаграмма А3 («to be»)

Далее был  декомпозирован уровень «выбор носителей  рекламы». На рис. 12 присутствует диаграмма  декомпозиции А31 «as is». На данной диаграмме представлен выбор носителей рекламы клиентов рекламного агентства.

Рис. 12. Диаграмма А31 («as is»)

Для второго и третьего функциональных блоков нижнего уровня IDEF0-модели были построены диаграммы декомпозиции в стандарте DFD – диаграммы потоков данных.

На рис. 13 и рис. 14. Представлены построенные  DFD – диаграммы «as is» и «to be»соответственно.

Рис. 13. DFD – диаграмма A34 «as is»

Рис. 14. DFD - диаграмма А34 «to be»

Из рис. 13 видно, что блок выбора материала  без условий выбора не может существовать в данной модели деятельности рекламного агентства. Поэтому был добавлен блок «условия выбора». Исходя из требований была построена DFD - диаграмма «to be».

3.2. Информационно-логическая модель рекламного агентства

Информационно-логическая модель деятельности рекламного агентства построена в графической нотации IDEF1X в программной среде ERwinDataModeler 7.3. Модель представлена на рис.15[7].

Предметная  область – рекламная компания.

Рис. 15. Информационно-логическая модель рекламного агентства

 

Структура разрабатываемой модели представлена в виде следующих сущностей:

• Счет клиента;
• Клиент;
• Заказ;
• Рекламное агентство;
• Счет компании;
• Реклама.

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

Счет клиента (табл. 1)

Таблица 1

Название атрибута	Тип данных	Размер поля
№ клиента	Числовой	Длинное целое
№ счета клиента	Числовой	Длинное целое
Денежные средства	Числовой	Длинное целое

 

Клиент (табл. 2)

Таблица 2

Название атрибута	Тип данных	Размер поля
№ клиента	Числовой	Длинное целое
Адрес	Текстовый	20
ФИО	Текстовый	20
Телефон	Числовой	Длинное целое
e-mail	Текстовый	20

 

Заказ (табл. 3)

Таблица 3

Название атрибута	Тип данных	Размер поля
№ клиента	Числовой	Длинное целое
№ заказа	Текстовый	20
Название	Текстовый	20
Дата	Дата
стоимость	Числовой	Длинное целое

 

 

 

 

 

 

Рекламное агентство (табл. 4)

Таблица 4

Название атрибута	Тип данных	Размер поля
Название	Текстовый	20
Адрес	Текстовый	20
Телефон	Числовой	Длинное целое
e-mail	Текстовый	20
№ заказа	Числовой	Длинное целое
№ клиента	Числовой	Длинное целое
№ счета компании	Числовой	Длинное целое

 

Счет компании (табл. 5)

Таблица 5

Название атрибута	Тип данных	Размер поля
№ счета	Числовой	Длинное целое
Денежные средства	Числовой	Длинное целое
Название	Текстовый	20

 

Реклама (табл. 6)

Таблица 6

Название атрибута	Тип данных	Размер поля
№ счета авиакомпании	Числовой	Длинное целое
№ клиента	Числовой	Длинное целое
№ заказа	Числовой	Длинное целое
дата	Дата
носитель	Текстовый	20
длительность	Числовой	Длинное целое