Разработка интеллектуальной информационной системы поддержки принятия решений

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 07.08.2018
Размер файла 1,6 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Внешний уровень (называемый также пользовательским) наиболее близок к пользователям, т.е. связан со способами представления данных для отдельных пользователей (прикладной программист или конечный пользователь). Для каждого пользователя может существовать свой язык СУБД. Для прикладного программиста - это язык программирования, а для конечного пользователя - это язык, основанный на меню, формах и т.д. Но все эти языки включают язык данных, встроенный в СУБД. Для каждого отдельного пользователя может быть интересна некоторая отдельная часть БД. Такие части, с которыми работает пользователь, называются внешним представлением.

Концептуальный уровень (называемый также логическим) является «промежуточным» уровнем между двумя первыми. Это представление всей информации БД в более абстрактной форме. На этом уровне хранятся собственно данные, независимые от формы их представления. Концептуальное представление состоит из множества экземпляров данных. Данные здесь представлены в виде концептуальной схемы. Кроме самих данных в эту схемы могут быть включены определения дополнительных средств, например, правила обеспечения целостности.

Размещено на http://www.allbest.ru/

Рис. 2.1 - Уровни архитектуры систем баз данных

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

Таблица 2. 1

Уровни представления данных

Уровни

Представления

Концептуальный:

Сущности, атрибуты, связи

Аналитик

Логический:

Записи, элементы данных, связи между записями

Программист

Физический:

Группирование данных, индексы, методы доступа

Пользователь

2.2 Требования, предъявляемые к базам данных

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

Рассматривать требования следует порознь, исходя из современных позиций, предъявляемые к транзакционным (операционным) базам данных и к хранилищам данных.

Первоначально перечислим основные требования, которые предъявляются к операционным базам данных, а, следовательно, и к СУБД, на которых они строятся.

1) Простота обновления данных. Под операцией обновления понимают добавления, удаления и изменения данных

2) Высокое быстродействие (малое время отклика на запрос).

Время отклика -- промежуток времени от момента запроса к БД и фактическим получением данных. Похожим является термин время доступа -- промежуток времени между выдачей команды записи (считывания) и фактическим получением данных. Под доступом понимается операция поиска, чтения данных или записи их

3) Независимость данных

4) Совместное использование данных многими пользователями

5) Безопасность данных -- защита данных от преднамеренного или непреднамеренного нарушения секретности, искажения или разрушения

6) Стандартизация построения и эксплуатации БД (фактически СУБД)

7) Адекватность отображения данных соответствующей предметной области.

8) Дружелюбный интерфейс пользователя

Важнейшими являются первые два противоречивых требования: повышение быстродействия требует упрощения структуры БД, что, в свою очередь, может затруднить процедуру обновления данных, увеличивает их избыточность [15].

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

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

Она предполагает:

- отсутствие неточно введенных данных или двух одинаковых записей об одном и том же факте;

- защиту от ошибок при обновлении БД;

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

- не искажение данных при работе в многопользовательском режиме и в распределенных базах данных;

- сохранность данных при сбоях техники (восстановление данных).

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

К хранилищам данных предъявляются следующие дополнительные требования:

- высокая производительность загрузки данных из операционных БД;

- возможность фильтрования, переформатирования, проверки целостности исходных данных, индексирования данных, обновления метаданных;

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

- высокая производительность запросов;

- обеспечение высокой размерности;

- одновременность доступа к ХД;

- наличие средств администрирования.

К современным базам данных, а, следовательно, и к СУБД, на которых они строятся, предъявляются следующие основные требования:

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

2) Простота обновления данных.

3) Независимость данных.

4) Возможность совместного использования данных многими пользователями.

5) Безопасность данных - защита данных от преднамеренного или непреднамеренного нарушения секретности, искажения или разрушения.

6) Стандартизация построения и эксплуатации БД (фактически СУБД).

7) Адекватность отображения данных соответствующей предметной области.

8) Дружелюбный интерфейс пользователя.

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

Стандартизация обеспечивает преемственность поколений СУБД, упрощает взаимодействие БД одного поколения СУБД с одинаковыми и различными моделями данных. В части интерфейса пользователя стандартизация (ANSI/SPARC) осуществлена в значительной степени СУБД и языка SQL. С помощью языка SQL и применением приложения Open DataBase connection (ODBC) можно успешно решить задачу взаимодействия различных реляционных СУБД. При этом может быть осуществлен как локальный, так и удаленный доступ к данным (технология клиент/сервер или сетевой вариант).

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

Процесс проектирования БД включает в себя следующие этапы:

- инфологическое проектировании;

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

- выбор системы управления базой данных (СУБД) и других инструментальных программных средств;

- логическое проектирование БД;

- физическое проектирование базы данных.

Концептуальное (инфологическое) проектирование -- построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Термины «семантическая модель», «концептуальная модель» и «инфологическая модель» являются синонимами. Кроме того, в этом контексте равноправно могут использоваться слова «модель базы данных» и «модель предметной области» (например, «концептуальная модель базы данных» и «концептуальная модель предметной области»), поскольку такая модель является как образом реальности, так и образом проектируемой базы данных для этой реальности. Пример концептуальной модели (рисунок 2.2).

Рис. 2.2 - Пример концептуальной модели

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

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

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

Трехуровневая архитектура (инфологическая, логическая, физическая модели) позволяет обеспечить независимость хранимых данных от использующих их программ. Разработчик может при необходимости переписать хранимые данные на другие носители информации или реорганизовать их физическую структуру, изменив физическую модель данных. АБД может подключить к системе любое число новых пользователей (новых приложений), дополнив логическую модель. Указанные изменения физической и логической моделей не будут замечены существующим пользователям системы, так как не будут замечены и новые пользователи. Следовательно, независимость данных обеспечивает возможность развития системы баз данных без разрушения существующих приложений.

Этапы создания интеллектуальных систем не являются четко очерченными и подробно регламентированными. Между некоторыми из них трудно провести временную и содержательную границу. Они в какой-то степени приблизительно описывают процесс проектирования интеллектуальных систем.

2.4 Разработка инфологической модели

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

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

Объекты базы данных в данном проекте:

1) персональные данные;

2) точка добычи;

3) виды работ на добыче;

4) график работы сотрудников;

5) график отпусков;

6) график запланированных проверок;

7) данные об объекте;

8) формирование рабочих групп на объект.

Рассмотри подробнее объекты базы данных вместе с их атрибутами.

1) Создание таблицы «Персональные данные» (таблица 2.2). Персонал предприятия характеризуется такими атрибутами как табельный номер, дата приема на работу, номер приказа, должность, точку добычи, фамилия, имя, отчество, разряд, дата рождения, адрес, телефон, номер свидетельства ОПС, ИНН, комментарий.

Таблица 2.2

Таблица «Персональные данные»

Описание

Тип данных

Табельный №

Числовой

Фамилия

Текстовый

Имя

Текстовый

Отчество

Текстовый

Дата приема на работу

Числовой

№ приказа

Числовой

Должность

Текстовый

Разряд

Числовой

Точка добычи

Текстовый

Дата рождения

Числовой

Адрес

Текстовый

Телефон

Числовой

Номер свидетельства ОПС

Числовой

ИНН

Числовой

Комментарий

Текстовый

2) Таблица «Точка добычи» (таблица 2.3) включает в себя все точки добычи нефти АО «Самараинвестнефть».

Таблица 2.3

Таблица «Точка добычи»

Описание

Тип данных

Идентификационный номер

Числовой

Точка добычи

Текстовый

3) Таблица «Виды работ на добыче» (таблица 2.4) содержит перечень возможных видов работ на точках добыче нефти.

Таблица 2.4

Таблица «Виды работ на добыче»

Описание

Тип данных

Идентификационный номер

Числовой

Вид работы на добыче

Текстовый

4) Таблица «График работы сотрудников» (таблица 2.5) включает в себя сведения о том работает ли сотрудник, выходной, находится на обучении, на больничном или на плановой проверке.

Таблица 2.5

Таблица «График работы сотрудников»

Описание

Тип данных

Идентификационный номер

Числовой

Табельный номер

Числовой

Дата

Числовой

Категория занятости

Текстовый

5) Таблица «График отпусков» (таблица 2.6) содержит в себе информацию о запланированных основных и дополнительных отпусках.

Таблица 2.6

Таблица «График отпусков»

Описание

Тип данных

Идентификационный номер

Числовой

Табельный номер

Числовой

Начало основного отпуска

Числовой

Окончание основного отпуска

Числовой

Кол-во дней основного отпуска

Числовой

Начало дополнительного отпуска

Числовой

Окончание дополнительного отпуска

Числовой

Кол-во дней дополнительного отпуска

Числовой

Общее кол-во дней отпуска

Числовой

Комментарий

Текстовый

6) Таблица «График запланированных проверок» (таблица 2.7) позволяет планировать проверки точек добычи соответственно периоду выполнения.

Таблица 2.7

Таблица «График запланированных проверок»

Описание

Тип данных

№ плана

Числовой

Дата

Числовой

Точка добычи

Текстовый

Название проверки

Текстовый

Статус

Текстовый

7) Таблица «Данные об объекте» (таблица 2.8) включает в себя данные об объекте.

Таблица 2.8

Таблица «Данные об объекте»

Описание

Тип данных

Идентификационный номер

Числовой

Точка добычи

Текстовый

Дата

Числовой

Состояние объекта

Текстовый

Кол-во устранения неполадок

Числовой

8) Таблица «Формирование рабочих групп на объект» (таблица 2.9) содержит информацию о сотрудниках, включающих в группу, а так же даты начала и окончания работ, наименование работ.

Таблица 2.9

Таблица «Формирование рабочих групп на объект»

Описание

Тип данных

Идентификационный номер

Числовой

Табельный номер

Числовой

Точка добычи

Текстовый

Дата начала работ

Числовой

Дата окончания работ

Числовой

Наименование работ

Текстовый

Комментарий

Текстовый

2.5 Физическое проектирование базы данных

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

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

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

В случае реляционной модели данных под этим подразумевается следующее:

- создание набора реляционных таблиц и ограничений для них на основе информации, представленной в глобальной логической модели данных;

- определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность СУБД;

- разработка средств защиты создаваемой системы.

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

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

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

Локальные базы данных - это FoxPro, Access, Paradox.

Данный проект реализуется в СУБД Visual FoxPro и SQL. Для нормального функционирования базы данных создаются таблицы, запросы, отчеты и формы. Для удобства пользователя - кнопочная форма.

Создание таблиц. На данном этапе в режиме Конструктора задаются названия полей, типы данных, маски ввода, размеры и описания полей, выбираются первичные и вторичные ключи (рис. 2.1-2.5).

Рис. 2.3 - Таблица «Персональные данные» в режиме конструктор

интеллектуальный информационный база данные

Рис. 2.4 - Таблица «Формирование рабочих групп на объекте» в режиме конструктор

Рис. 2.5 - Таблица «График запланированных проверок» в режиме конструктор.

Схема данных. На данном этапе создается база данных, к ней добавляются все созданные ранее таблицы, выносятся на схему данных, где между ними устанавливаются все необходимые связи (рис. 2.6).

Рис. 2.6 - Схема данных реализуемого проекта

2.6 Проектирование базы знаний

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

Можно выделить следующие этапы:

1) данные как результат измерений и наблюдений;

2) данные на материальных носителях информации (таблицы, протоколы, справочник, энциклопедии)

3) модели (структуры) данных, представленных в виде диаграмм, функций, графиков;

4) данные в компьютере на языке описания данных;

5) базы данных на машинных носителях информации.

При обработке на компьютере знания преобразуются аналогично данным:

1) знания в памяти человека как результат мышления;

2) материальные носители информации (энциклопедии, словари, учебники, учебные пособия);

3) поле знаний - условное описание основных объектов данной предметной области, их атрибутов и закономерностей, их объединяющих;

4) знания, представленные на языках описания знаний (продукционные языки, семантические сети, фреймы);

5) база знаний на машинных носителях информации.

Знания можно классифицировать двумя способами:

1) поверхностные - это знания об определённых взаимосвязях между событиями и фактами в данной предметной области; глубинные - это абстракции, аналогии, схемы, отображающие структуру и природу процессов (глубинные знания можно использовать для прогнозирования процессов, протекающих в данной предметной области);

2) процедурные - знания, определённые с помощью алгоритмов; декларативные - структурирование знаний с помощью таблиц, списков, абстрактных понятий.

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

Модели представления знаний можно классифицировать следующим образом:

1) продукционные модели;

2) семантические сети;

3) фреймы;

4) формальные логические модели.

Под продукционной моделью понимается способ представления знаний в виде предложений типа "Если (условие), то (действие). Характерными признаками продукционной модели является наглядность, высокая модульность, лёгкость внесения дополнений и изменений в базу знаний.

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

- класс - элемент класса;

- свойство - значение;

- пример элемента класса.

В классификации семантических сетей можно выделить следующие:

1. по количеству типов отношений:

- однородные (с единственным типом отношений);

- неоднородные (с различными типами отношений);

2. по типам отношений:

- бинарные (в них отношения связывают два объекта);

- N -арные (отношения в них связывают более двух понятий).

Чаще всего в семантических сетях применяют следующие отношения:

- связи типа "часть - целое" ("класс - подкласс");

- функциональные связи;

- количественные (больше, меньше, равно);

- пространственные (далеко от, близко от, под, над :);

- временные (в течение, позже:);

- логические (и, или, не);

- атрибутивные иметь свойство, иметь значение);

- лингвистические.

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

В типологии фреймов различают:

- фреймы - образцы или прототипы, находящиеся в базе знаний;

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

В моделях фреймов можно отобразить знания с помощью следующих вариантов:

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

- фреймы - роли;

- фреймы - сценарии;

- фреймы - ситуации.

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

Формальные логические модели представления знаний основаны на описании предметной области в виде совокупности аксиом.

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

Правила опишем в таблице 2.10.

Таблица 2.10

Правила вывода решений для определения сотрудников в бригаду на объект

IF

(Если)

<условие>

Then

(Тогда)

<действие>

1

Если

Поступила заявка

Тогда

Формирование бригады на объект

2

Если

Специалист 1 свободен

Тогда

Переход к действию 1

3

Если

Специалист 2 свободен

Тогда

Переход к действию 1

4

Если

Специалист N свободен

Тогда

Переход к действию 1

5

Если

Специалист 1 занят

Тогда

Переход к действию 3

6

Если

Специалист 1 в основном отпуске

Тогда

Переход к действию 3

7

Если

Специалист 1 в дополнительном отпуске

Тогда

Переход к действию 3

8

Если

Специалист 1 на больничном

Тогда

Переход к действию 4

9

Если

Специалист 2 занят

Тогда

Переход к действию 4

10

Если

Специалист 2 в основном отпуске

Тогда

Переход к действию 4

11

Если

Специалист 2 в дополнительном отпуске

Тогда

Переход к действию 4

12

Если

Специалист 2 на больничном

Тогда

Переход к действию 4

13

Если

Специалист 1 и Специалист 2 занят

Тогда

Переход к действию 4

14

Если

Специалист 1 и Специалист 2 в основном отпуске

Тогда

Переход к действию 4

15

Если

Специалист 1 и Специалист 2 в дополнительном отпуске

Тогда

Переход к действию 4

16

Если

Специалист 1 и Специалист 2 на больничном

Тогда

Переход к действию 4

18

Если

Специалист 1, Специалист 2, … специалист N занят

Тогда

Переход к базе внештатных сотрудников

19

Если

Устранен дефицит сотрудников

Тогда

Отчет об формировании

Рассмотренные правила приведены в качестве примера для качественного решения по формированию бригады.

2.7 Создание пользовательского интерфейса

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

Кнопочная форма создается следующим образом. Сначала в пустую форму надо добавить нужное количество компонентов Command Button и один компонент Image, установить значения их свойств (рис. 2.7).

Рис. 2.7 - Создание основной формы

Для кнопок нужно указать выполняемые действия. Так при нажатии на кнопку «Персональные данные» откроется форма, содержащая в себе все данные о сотрудниках компании.

Выбрав кнопку «точка добычи», откроется окно, в котором содержится вся информация об объектах добычи. «Данные об объекте» список всех объектов, которые есть у компании. «График работы сотрудников» учитывает всю посещаемость сотрудников, а так же позволяет выяснить причину отсутствия, например, болеет сотрудник или выходной. В «Графике отпусков» говорится о том, когда и в какое время сотрудник планирует отдыхать. При нажатии на кнопку «График запланированных проверок» мы получим информацию о запланированных проверках. Если нажать кнопку «Формирование рабочих групп на объект», то система нам сформирует необходимые данные об объекте, дате ремонтных работ, наименовании работ, а так же сотрудниках, которые будут эти работы проводить (рис. 2.9).

Рис. 2.8 - Формирование рабочих групп на объект

3. Экспериментальная часть

3.1 Программное обеспечение функционирования интеллектуальной информационной системы

3.1.1 Алгоритм работы программы

Рис. 3.1 - Алгоритм работы

3.1.2 Экранные формы

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

Рис. 3.2 - Главное меню

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

На рис. 3.3 - Окно приветствия

На рисунке 3.4 определяется количество специалистов и их вид, что бы отправить на объект.

Рис. 3.4 - Начало работы, подсчет нужных специалистов

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

Рис. 3.5 - Выбор объектов

На рисунке 3.6 показано окно интеллектуальной инфомационной системы поддержки приняит решений, в котором видно соотношение типов и колличества специалистов, направляемых на объекты на которых им предстоит работать.

Рис. 3.6 - Подсчет количества специалистов на объекты

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

Рис. 3.7 - Подсчет количества недостающих специалистов

На рисунке 3.8 осуществляется подбор внештатных сотрудников, в случае нехватки штатных рабочих.

Рис. 3.8 - Привлечение внештатных сотрудников

На рисунке 3.9 вводим данные о колличестве нужных специалистов.

Рис. 3.9 - Процесс подсчета нужного количества специалистов

На рисунке 3.10 изобрежен финальный подсчет сотрудников на объекты после процесса привлечения внештатных сотрудников.

Рис. 3.10 - Подсчет специалистов после привлечения внештатных сотрудников

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

Рис. 3.11 - Вывод о достаточности специалистов после привлечения внештатных сотрудников

Рис. 3.12 - Вывод об окончании процесса формирования

3.2 Тестирование ИИС поддержки принятия решений

Данные контрольного примера приведены в таблице 3.1

Таблица 3.1

Исходные данные

Параметр

Значение

Тип специалиста

1;5

Количество специалистов

1;12

Тип объекта

2;1

Количество объектов

2

Анализ полученных результатов экспертизы (Рис.3.13 - 3.19)

Рис. 3.13 - Выбор типа объекта

Рис. 3.14 - Подсчет количества специалистов

Рис. 3.15 - Вывод о достаточности специалистов

Рис. 3.16 - Привлечение внештатных сотрудников

Рис. 3.17 - Процесс подсчета нужного количества специалистов

Рис. 3.18 - Подсчет специалистов после привлечения внештатных сотрудников

Рис. 3.19 - Вывод о достаточности специалистов после привлечения внештатных сотрудников

По данным контрольного примера были получены следующие результаты:

1) Устранен дефицит специалистов типа 1 на объект 2

2) Устранен дефицит специалистов типа 5 на объект 1

3.3 Обоснование экономической эффективности разработки

Определим себестоимость разработки системы, результаты представим в виде следующей таблицы 3.2.

Таблица 3.2

Себестоимость разработки системы

Наименование статей затрат

Сумма, руб.

Основная заработная плата

84952,64

Дополнительная заработная плата (10%)

8495,26

Страховые взносы (30%), руб.

28034,37

Стоимость материалов и покупных изделий, руб.

5950,00

Прочие прямые расходы, руб.

5440,40

Итого, руб.

132872,67

Таким образом, капитальные затраты на разработку программы составят 132872,67 рублей.

ИИС поддержки принятия решений используется в среднем 19 дней в месяце.

Расчет годовых расходов на электроэнергию при решении задачи с применением ИИС поддержки принятия решений представлен в табл. 3.3

Таблица 3.3

Расчет годовых расходов на электроэнергию при решении задачи с применением ИИС поддержки принятия решений

Вид оборудования

Количество

Потребляемая мощность

Время работы, часы

Тариф за 1 кВт·час, руб.

Общая сумма расходов, руб.

Компьютер

1

0,7

842,40

6,30

4245,70

Освещение

0,3

842,40

6,30

1592,14

Кондиционеры

1

0,8

210,60

6,30

1061,42

Общая сумма расходов

6899,26

Перейдем к рассмотрению другой статьи затрат - амортизационные отчисления.

Расчет амортизационных отчислений при решении задачи с применением ИИС поддержки принятия решений представлен в табл. 3.4.

Таблица 3.4

Расчет амортизационных отчислений при решении задачи с применением ИИС поддержки принятия решений

Наименование основного средства

Количество

Цена, руб.

Стоимость, руб

Норма амортизации, %

Амортизация, руб.

Компьютер

1

30000

30000

10%

3000,00

Компьютерный стол

1

3000

3000

5%

150,00

Общая сумма

3150,00

Расчёт годовых эксплуатационных расходов при решении задач с применением советующей ИС представлен в таблице 3.5.

Таблица 3.5

Годовые эксплуатационные расходы при решении задач с применением ИИС поддержки принятия решений

Наименование статьи расходов

Сумма, руб.

Основная заработная плата (ЗПос)

137612,59

Дополнительная заработная плата (ЗПд)

13761,26

Страховые взносы

45412,16

Амортизационные отчисления

3150,00

Затраты на электроэнергию

6899,26

Общая сумма затрат (Э1)

206835,27

Трудоемкость решения задачи без использования советующей ИС приведена в таблице 3.6

Таблица 3.6

Трудоемкость решения задач специалистом по кадрам без применения ИИС поддержки принятия решений

Операция

Трудоемкость, чел-час

Получение информации об участках работ

1,1

Получение информации о влиянии внешних факторов

0,6

Получение информации о сроках ремонта

0,7

Оценка сроков

0,2

Составление списка сотрудников

0,3

Оценка сроков работы сотрудников на участках

1

Составление списка сотрудников

1

Поиск подходящих сотрудников

0,6

Выбор сотрудников

0,9

Итого

6,4

Амортизационные отчисления при решении задачи без применения советующей ИС будут такими же, как и с её применением.

Годовые затраты на электроэнергию при решении задачи без применения ИИС поддержки принятия решений представлены в табл. 3.7.

Таблица 3.7

Расчет годовых расходов на электроэнергию при решении задачи без применения ИИС поддержки принятия решений

Вид оборудования

Количество

Потребляемая мощность

Время работы, часы

Тариф за 1 кВт·час, руб.

Общая сумма расходов, руб.

Компьютер

1

0,7

1459,20

6,30

6435,07

Освещение

0,3

1459,20

6,30

2757,89

Кондиционеры

1

0,8

364,80

6,30

1838,59

Общая сумма расходов

11031,55

Расчет годовых эксплуатационных расходов при решении задачи без ИИС поддержки принятия решений представлен в таблице 3.8

Таблица 3.8

Годовые эксплуатационные расходы при решении задачи без применения ИИС поддержки принятия решений

Наименование статьи расходов

Сумма, руб.

Основная заработная плата (ЗПос)

225825,79

Дополнительная заработная плата (ЗПд)

22582,58

Страховые взносы

74522,51

Амортизационные отчисления

3150,00

Затраты на электроэнергию

11031,55

Общая сумма затрат (Э2)

337112,43

Ежегодная экономия текущих затрат (доходы от использования системы) составят: Д = Э2 - Э1 = 337112,43 - 206835,27 = 130277,16 рублей.

Составим таблицу движения денежных средств (таблица 3.9).

Таблица 3.9

Таблица движения денежных средств

Наименование статьи

Годы

Всего

2017

2018

2019

2020

Инвестиционная деятельность (ИД), рублей

132872,67

132872,67

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

Заключение

В данной бакалаврской работе была разработана интеллектуальная информационная система поддержки принятия решений. Интеллектуальная информационная система поддержки принятия решений позволяет: осуществлять ведение сведений о персонале предприятия необходимых для учета; получать информацию о запланированных отпусках и прочих неявках персонала; распределять персонал на объектах с указанием даты начала и окончания работ; планировать распределение персонала на объектах; осуществлять расчёт нормативного состава специалистов для выполнения работ; осуществлять расчёт степени оптимизации распределения персонала на объектах.

В аналитической части бакалаврской работы были приведены технико-экономическая характеристика предприятия АО «Самараинвестнефть»; обоснование необходимости и цели созданная интеллектуальной информационной системы и использования вычислительной техники для решения данного комплекса задач; дано обоснование проектных решений по информационному обеспечению проектируемой системы.

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

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

Размещено на Allbest.ru


Подобные документы

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

    дипломная работа [1,9 M], добавлен 10.07.2017

  • Обслуживание двух встречных потоков информации. Структура информационных систем. Разработка структуры базы данных. Режимы работы с базами данных. Четыре основных компонента системы поддержки принятия решений. Выбор системы управления баз данных.

    курсовая работа [772,0 K], добавлен 21.04.2016

  • Анализ существующих решений системы поддержки принятия решений для корпоративной сети. Многоагентная система. Разработка концептуальной модели. Структура базы знаний. Разработка модели многоагентной системы на базе сетей Петри. Методика тестирования.

    дипломная работа [5,1 M], добавлен 19.01.2017

  • Основные модели представления знаний. Системы поддержки принятия решений. Диаграмма UseCase. Разработка базы данных на основе трех моделей: продукционные правила, семантическая сеть, фреймовая модель. Программная реализация системы принятия решений.

    курсовая работа [715,1 K], добавлен 14.05.2014

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

    дипломная работа [1,9 M], добавлен 11.04.2013

  • Типы административных информационных систем: системы генерации отчетов, системы поддержки принятия решений, системы поддержки принятия стратегических решений. Сортировка и фильтрация списков в Microsoft Excel. Работа с базами данных в Microsoft Access.

    контрольная работа [6,0 M], добавлен 19.11.2009

  • Методы решения проблем, возникающих на стадиях и этапах процесса принятия решений, их реализация в информационных системах поддержки принятия решений (СППР). Назначение СППР, история их эволюции и характеристика. Основные типы СППР, области их применения.

    реферат [389,3 K], добавлен 22.11.2016

  • Описание предметной области автоматизации. Программа обследования и план-график выполнения работ на предпроектной стадии. Метод группового принятия решения с помощью кластеризации экспертных оценок альтернатив. Построение диаграммы потоков данных DFD.

    дипломная работа [375,8 K], добавлен 07.12.2014

  • Разработка базы данных для информационной поддержки деятельности аптеки с целью автоматизированного ведения данных о лекарствах аптеки. Проектирование схемы базы данных с помощью средства разработки структуры базы данных Microsoft SQL Server 2008.

    курсовая работа [3,6 M], добавлен 18.06.2012

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

    курсовая работа [37,4 K], добавлен 01.12.2009

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.