Курсовые работы / ПРИС К_13

сопровождаются;

–имеется простой программный интерфейс;

–возможности языка можно расширить при помощи библиотек,

написанных на C или Ruby;

– дополнительные возможности для обеспечения безопасности.

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

В качестве СУБД была использована PostgreSQL, клиент для работы с базой данных (БД) pgAdmin3. Данный выбор обусловлен опытом работы с данной СУБД [10]. Календарный план проектирования и разработки информационной системы для учета работы сотрудников в газообеспечивающей компании представлен на рисунке В.1.

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

Функциональная модель бизнес-процессов разрабатываемой информационной системы представлена в приложении В на рисунках Г.1-Г.7.

Целью моделирования является упрощение автоматизации процесса учета работы сотрудников для организации по газовому обеспечению, то есть повышение эффективности процесса. Функциональная модель построена с точки зрения интегрированного пользователя: руководителя отдела кадров,

работников аварийно-диспетчерской службы и начальника отдела по охране труда, а также с точки зрения администратора и разработчика проектируемой системы. Это обусловлено тем, что именно данным лицам будет необходимо работать с информационной системой [11-13].

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

22

которые представлены на рисунке 2.1.

Рисунок 2.1 – Иерархическое дерево работ

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

коэффициент уровня, рассчитываемый по формуле (2.1); коэффициент сбалансированности, рассчитываемый по формуле (2.2); и коэффициент применения элементарных функций, рассчитываемый по формуле (2.3).

(2.1)

(2.2)

(2.3)

где N – количество работ на текущем уровне; L – номер уровня; Ai – стрелки,

входящие и выходящие в функцию; Nэл.ф. – количество элементарных функций.

От уровня к уровню Kи должен уменьшаться (или хотя бы не возрастать).

Kб, в идеале, равен нулю, однако допускаются значения в пределах от 2 до 3.

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

23

функциональной модели. Если Кф>1 и >0,5, то продолжать декомпозицию не надо.

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

-прием на работу;

-увольнение сотрудника;

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

-определение полномочий пользователя;

-открытие доступа к БД;

-сортировка по бригадам;

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

командировочных и пр.;

-мониторинг выполнения графика работ;

-смена пароля;

-резервное копирование БД;

-мониторинг работы системы;

-расширение функций пользователей по управлению системой;

-оперативное восстановление системы;

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

-проведение обучений и сдачи экзамена по технике безопасности;

-мониторинг прохождения техники безопасности;

-регистрация сообщения и направление бригады на место аварии;

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

-выполнение ремонтных работ;

-учет локализации аварий.

На основе данного списка был заполнен 4-й столбец таблицы 2.1

24

(количество элементарных функций на уровне – Nэл.ф).

Таблица 2.1 – Результаты количественного анализа функциональной модели

Таким образом, исходя из таблицы 2.1, можно сделать вывод, что коэффициент уровня имеет тенденцию уменьшения, коэффициент сбалансированности, в основном, находится в пределах от 0 до 3, что не превышает норму, однако, на 1 уровне выходит за рамки допустимых значений в виду слишком подробного и детализированного описания стрелок, а

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

достаточно сбалансирована и детализирована.

2.4 Построение логических и физических моделей данных бизнес-

процесса учета работы сотрудников в газоснабжающей компании

Целью построения логической модели предметной области разработки,

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

– свойства этих объектов и субъектов [14-17].

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

25

построенная в соответствии со стандартом IDEF1X изображена на рисунке 2.2.

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

1) Сотрудники компании: код, имя, фамилия, отчество сотрудника, дата рождения, занимаемая должность, заработная плата, рабочий номер телефона,

фотография;

2)Техника безопасности: код, проверяющийся сотрудник, дата прошлой проверки, результат прошлой проверки, дата следующей проверки;

3)Виды графиков работ в компании: код, продолжительность, время

начала;

4)Текущий график работ сотрудников: код, сотрудник, вид графика работ по договору, отработанное фактическое время, дата, наличие нарушения на данное число;

5)Произошедшие нарушения графика работ: код, сотрудник, разъяснение причины нарушения, дата;

6)Виды ремонтных работ, осуществляемых компанией: код,

наименование, стоимость; 7) Выезды на места аварий: код, сотрудник, вид ремонтной работы, дата

происшествия, адрес происшествия, результат реализации ремонта.

Рисунок 2.2 – Логическая модель данных по стандарту IDEF1X

Взаимосвязи между объектами отражаются взаимодействием между двумя сущностями, называемым «один-ко-многим». Также, чтобы

26

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

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

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

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

Схема рассматривается как группа объектов, связанных друг с другом в базе данных. Таблицы и столбцы производятся в соответствии с информацией,

предоставленной во время построения логической модели [18-19]. Физическая модель данных разрабатываемой информационной системы для автоматизации учета работы сотрудников газообеспечивающей компании, построенная в соответствии со стандартом IDEF1X для СУБД PostgreSQL, изображена на рисунке 2.3.

Рисунок 2.3 – Физическая модель данных по стандарту IDEF1X

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

процессе учета работы сотрудников газообеспечивающей компании.

27

Выводы по второму разделу

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

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

Также были построены следующие модели для последующего проектирования ИС: функциональная модель бизнес-процесса по стандарту

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

28

3 РАЗРАБОТКА И ТЕСТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ ДЛЯ АВТОМАТИЗАЦИИ УЧЕТА РАБОТЫ СОТРУДНИКОВ РЕГИОНАЛЬНОЙ ГАЗООБЕСПЕЧИВАЮЩЕЙ КОМПАНИИ

3.1 Описание таблиц баз данных

База данных для разрабатываемой информационной системы для автоматизации процесса учета работы сотрудников газообеспечивающей компании была построена в СУБД PostgreSQL.

Для обеспечения работоспособности информационной системы в соответствии с заданием, было создано 8 справочников:

-таблица «Сведения о сотрудниках компании»;

-таблица «Виды графиков работ в компании»;

-таблица «Сведения о текущем графике работ сотрудников»;

-таблица «Сведения о произошедших нарушениях графика работ»;

-таблица «Виды ремонтных работ, осуществляемых компанией»;

-таблица «Выезды на места аварий»;

-таблица «Техника безопасности»;

-таблица «Пользователи».

Вприложении Д представлено описание данных таблиц. На рисунках 3.1-

3.8представлены разработанные справочники с наполнением.

29

Рисунок 3.1 – Справочник «Сведения о сотрудниках компании» разрабатываемой информационной системы

Рисунок 3.2 – Справочник «Виды графиков работ в компании» разрабатываемой информационной системы

Рисунок 3.3 – Справочник «Сведения о текущем графике работ сотрудников» разрабатываемой информационной системы

30

Рисунок 3.4 – Справочник «Сведения о произошедших нарушениях графика работ» разрабатываемой информационной системы

Рисунок 3.5 – Справочник «Виды ремонтных работ, осуществляемых компанией» разрабатываемой информационной системы

Рисунок 3.6 – Справочник «Выезды на места аварий» разрабатываемой информационной системы

Рисунок 3.7 – Справочник «Техника безопасности» разрабатываемой информационной системы

Рисунок 3.8 – Справочник «Пользователи» разрабатываемой информационной системы

31