Курсовые работы / ПРИС К_1
.pdfорганизации, структурирование алгоритма работы, получение необходимой аналитической информации с возможностью детализации.
Основными предполагаемыми пользователями системы является:
администратор БД;
пользователь;
гость.
Администратор – лицо, ответственное за удаление сведений из базы данных, а также изменение пароля для входа в систему, резервное копирование базы данных, за подключение к нужной базе данных. Он имеет доступ ко всем пунктам главного меню системы, возможность редактирования всех объектов системы.
Сотрудник ‒ лицо, отвечающее за ввод данных в систему. Лицо не имеет доступа к конфигурации системы, не имеет осуществления смены пароля и резервного копирования базы. Так же сотрудник не может интерактивно удалять записи в базе данных, ему доступна лишь оперативная памятка на удаление.
Гость ‒ лицо, не имеющее существенных прав. Имеет право на просмотр некоторых отчётов.
Входные и выходные документы для разрабатываемой ИС учета рабочего времени сотрудников, имеют форму бумажных носителей.
Входным документом является унифицированная форма Т-12 ‒ документ двойного назначения [7-8].
Выходными документами выступают:
Отчет обо всех авариях, которые были локализованы в заданный пользователем промежуток времени.
Отчет о том, сотруднике, который участвовал больше других в локализации аварий (ремонтов) за заданный пользователем промежуток времени.
Отчет работы сотрудников в текущем месяце.
22
Отчет о тех авариях, которые не удалось локализовать в срок (в
соответствии с нормативами), за заданный пользователем промежуток времени.
Программный продукт будет разрабатываться на языке программирования Ruby, инструментом разработки является фреймворк Ruby on Rails. Обосновано это решение тем, что Ruby on Rails является средой,
облегчающей разработку, развертывание и обслуживание веб-приложений. В
Ruby on Rails также включены локальный SQL-сервер, библиотеки визуальных компонентов, генераторы отчетов, и все то, что необходимо для разработки необходимого приложения. Кроме того, Rails использует все возможности
Ruby, являясь его оригинальным расширением, облегчающим жизнь программистов. Программы становятся короче, читаются легче. Это также позволяет нам выполнять те задачи, которые иначе выполнялись бы в исходном коде внешних файлов конфигурации, что облегчает понимание происходящего
[9-10].
Rails-приложения пишутся на Ruby ‒ современном объектно-
ориентированном языке сценариев. Лаконичность кода Ruby не влияет на его разборчивость ‒ свои идеи на этом языке можно выражать вполне четко и естественно.
У Ruby on Rails есть много преимуществ, при сопоставлении с аналогичными программными продуктами.
скорость разработки приложения;
высокая производительность у разработанного программного продукта;
низкие требования к ресурсам компьютера у разработанного приложения;
наращиваемость за счет встраивания новых компонент и инструментов
всреду;
удачная проработка иерархии объектов.
Таким образом, возможности Ruby on Rails полностью отвечают
требованиям и подходят для создания необходимого программного продукта.
23
В качестве СУБД выбрано PostgreSQL, клиент для работы с БД pgAdmin3, так как присутствует опыт работы, так же СУБД удобна для использования [11].
2.3 Построение функциональных моделей, описывающих бизнес-процесс учета рабочего времени сотрудников в железнодорожной обслуживающей организации
Функциональная модель бизнес-процессов разрабатываемой информационной системы представлена в приложении B на рисунках B.1-B.5.
Целью моделирования является упрощение автоматизации процесса учета рабочего времени сотрудников для железнодорожной обслуживающей организации, то есть повышения эффективности процесса.
Функциональная модель построена с точки зрения интегрированного пользователя: работников производства, менеджеров, а также с точки зрения разработчика. Это обусловлено тем, что с системой необходимо работать как сотрудников подразделений производства, так и менеджера, который непосредственно занят работой и сопровождением с информационной системой
[8].
Следовательно, при моделировании системы учета рабочего времени сотрудников в железнодорожной обслуживающей организации были выделены следующие работы, которые представлены на рисунке 2.1.
24
Рисунок 2.1 ‒ Иерархическое дерево работ
Для проведения количественного анализа разработанной функциональной модели необходимо рассмотреть поведение следующих показателей:
коэффициент уровня, рассчитываемый по формуле (2.1); коэффициент сбалансированности, рассчитываемый по формуле (2.2); и коэффициент применения элементарных функций, рассчитывается по формуле (2.3).
(2.1)
(2.3)
где N ‒ количество работ на текущем уровне; L ‒ номер уровня; 
‒ стрелки,
входящие и выходящие в функцию; 
‒ количество элементарных функций.
От уровня к уровню 
должно уменьшаться (или хотя бы не возрастать). 
в
идеале равен нулю, однако допускаются значения в пределах от 2 до 3.
Коэффициент сбалансированности показывает соотношения входных и выходных стрелок. Коэффициент применения элементарных функций необходим для определения необходимости дальнейшей детализации
25
функциональной модели. Если |
и |
, то продолжать |
декомпозицию не надо [12-13].
Результаты расчёта коэффициентов для каждого уровня представлены в таблице 2.1. Для расчёта коэффициента применения элементарных функций за элементарные функции процесса учета рабочего времени сотрудников были приняты работы, отраженные в списке элементарных функций (приложение Д).
На основе данного списка бал заполнен 4-й столбец таблицы 2.1.
Таблица 2.1 ‒ Результаты количественного анализа функциональной модели
Номер уровня |
|
|
|
|
|
|
|
|
|
|
|
1(А0) |
- |
- |
- |
- |
- |
|
|
|
|
|
|
2(А1) |
4 |
0,5 |
4 |
1 |
1 |
|
|
|
|
|
|
2(А2) |
1,5 |
0 |
3 |
2 |
1 |
|
|
|
|
|
|
2(А3) |
1,6 |
0 |
5 |
3 |
1 |
|
|
|
|
|
|
Таким образом, исходя из таблицы 2.1, можно сделать вывод, что коэффициент уровня имеет тенденцию уменьшения, коэффициент сбалансированности находиться в пределах от 0 до 3, что не превышает норму,
а коэффициент применения элементарных функций говорит о достаточной декомпозиции работ. Значит, построенная функциональная модель качественна,
сбалансирована и достаточно детализирована.
2.4 Построение логических и физических моделей данных бизнес-
процесса учета рабочего времени сотрудников в железнодорожной обслуживающей организации
26
Целью построения логической модели предметной области разработки,
является получения графического представления логической структуры исследуемой предметной области. Логическая модель иллюстрирует сущности разрабатываемой ИС и отражает их взаимоотношения, где сущности описывают объекты и субъекты деятельности предметной области, а атрибуты свойства этих объектов и субъектов.
Логическая и физическая модели данных разрабатываемой информационной системы для автоматизации учета времени сотрудников,
построенные в соответствии со стандартом IDEF1X изображены на рисунке
2.2-2.3.
Рисунок 2.2 ‒ Логическая модель данных по стандарту IDEF1X
27
Рисунок 2.3 ‒ Физическая модель данных по стандарту IDEF1X
Анализ предметной области разработки ИС позволил нам выделить следующие сущности и атрибуты:
1)Вид аварии: код, вид аварии, нормативный срок ремонта.
2)Аварии: код, вид аварии, сотрудник, дата аварии, дата локализации аварии, результат ремонта.
3)Сотрудник: код, фамилия, имя, отчество, день рождения, должность,
фото.
4)Нарушения графика: сотрудник, дата, причина.
5)График: сотрудник, дата и время начало работы, длительность рабочего дня.
6)Вид графика: режим рабочего времени.
7)Должности: оклад, наименование.
Физическая модель ИС в соответствии с предметной областью была построена на основании вышеописанной логической модели, а также особенностями среды разработки данной ИС, а именно «Ruby on Rails».
Выводы по второму разделу
28
В результате написания второго раздела курсового проекта был проведен анализ предметной области, выявлены категории пользователей разрабатываемого приложения.
Также была определена цель и задачи разработки информационной системы, которая предназначена для автоматизации процесса учета рабочего времени сотрудников железнодорожной обслуживающей организации.
Были построены следующие модели для последующего проектирования ИС: функциональная модель бизнес-процесса по стандарту IDEF0, логическая и физическая модель данных по стандарту IDEF1X.
29
3 РАЗРАБОТКА И ТЕСТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ ДЛЯ АВТОМАТИЗАЦИИ УЧЕТА РАБОЧЕГО ВРЕМЕНИ СОТРУДНИКОВ В ЖЕЛЕЗНОДОРОЖНОЙ ОБСЛУЖИВАЮЩЕЙ ОРГАНИЗАЦИИ
3.1 Описание таблиц баз данных
База данных для разрабатываемой информационной системы для автоматизации процесса учета рабочего времени сотрудников была построена в СУБД PostgreSQL с помощью клиента pgAdmin3. В приложении Г представлен план курсового проекта в программном продукте Microsoft project.
Для обеспечения работоспособности ИС в соответствии с заданием, было создано: 6 справочников и 4 отчета. Справочники: аварии, вид аварии,
сотрудники, нарушения графика, график, вид графика. Отчеты: поиск локализованных аварий за дату, отчет работы сотрудников по дате, о авариях не локализованных в срок, сотрудник участвующих больше всего в авариях.
Структура вышеперечисленных справочников и их метод хранения в базе данных разрабатываемой ИС представлено в таблицах 1-4.
Таблица 4.1 – Таблица Аварии
Название |
Название поля |
Тип поля |
Примечание |
Разрешает |
таблицы |
|
|
|
Null |
avars |
ID |
Integer |
Генерируется |
|
(Аварии) |
|
|
самостоятельно |
|
|
id_vid (вид аварии) |
belongs_to |
Берется из таблицы |
|
|
|
|
вид аварии |
|
|
ID Сотрудника |
belongs_to |
Берется из таблицы |
|
|
|
|
сотрудники |
|
|
datanahal |
date |
|
|
|
(Дата аварии) |
|
|
|
|
data_k (Дата локализации |
date |
|
|
|
аварии) |
|
|
|
|
result (Результат) |
string |
|
|
|
status |
boolean |
|
|
|
s_delete |
boolean |
|
|
|
created_at |
timestamp |
Генерируется |
|
|
|
|
самостоятельно |
|
|
updated_as |
timestamp |
Генерируется |
|
|
|
|
самостоятельно |
|
30
Таблица 4.2 – Таблица Сотрудники
Название |
Название поля |
Тип поля |
Примечание |
Разрешает |
|
таблицы |
|
|
|
|
Null |
sotrs |
ID |
|
Integer |
Генерируется |
|
(Сотрудники) |
|
|
|
самостоятельно |
|
|
fam (Фамилия) |
string |
|
|
|
|
name |
(Имя) |
string |
|
|
|
otch |
(Отчество) |
string |
|
|
|
datebirdth (Дата |
Date |
|
|
|
|
рождения) |
|
|
|
|
|
ID dolg |
belongs_to |
Берется из таблицы |
|
|
|
(Должность) |
|
должности |
|
|
|
photo |
string |
|
Может быть |
|
|
(Фотография) |
|
|
пустым |
|
|
status |
boolean |
|
|
|
|
s_delete |
boolean |
|
|
|
|
created_at |
timestamp |
Генерируется |
|
|
|
|
|
|
самостоятельно |
|
|
updated_as |
timestamp |
Генерируется |
|
|
|
|
|
|
самостоятельно |
|
Таблица 4.3 – Таблица Вид аварии
Название таблицы |
Название поля |
Тип поля |
Примечание |
Разрешает |
|
|
|
|
Null |
vids (Виды аварий) |
ID |
Integer |
Генерирует |
|
|
|
|
самостоятельно |
|
|
vid (Вид аварии) |
string |
|
|
|
norm (Нормативный срок |
Integer |
|
|
|
ремонта(ч)) |
|
|
|
|
status |
boolean |
|
|
|
s_delete |
boolean |
|
|
|
created_at |
timestamp |
Генерируется |
|
|
|
|
самостоятельно |
|
|
updated_as |
timestamp |
Генерируется |
|
|
|
|
самостоятельно |
|
Таблица 4.4 – Таблица Должностей
Название |
Название поля |
Тип поля |
Примечание |
Разрешае |
таблицы |
|
|
|
т |
|
|
|
|
Null |
dolgs |
ID |
Integer |
Генерируется самостоятельно |
|
(Должности) |
|
|
|
|
|
name (Название |
string |
|
|
|
должности) |
|
|
|
|
oklad (Оклад) |
Integer |
|
|
|
status |
boolean |
|
|
|
s_delete |
boolean |
|
|
|
created_at |
timestamp |
Генерируется самостоятельно |
|
|
|
|
|
|
|
updated_as |
timestamp |
Генерируется самостоятельно |
|
31