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


Чтобы посмотреть этот PDF файл с форматированием и разметкой, скачайте его и откройте на своем компьютере.
МИНОБРНАУКИ РОССИИ

Санкт
-
Петербургский государственный электротехнический университет ‮ЛЭТИ 

им. В.И. Ульянова Ленина)




аправл ни

-9 -4 -2 «Информа ионны сист мы и т
х-
нологии»



Профил

аспр л нны вычислит л ны ко
м-
пл ксы сист м р ал ного вр м ни



Факул т т

омп ют рных т хнологий и информатики



аф ра

Информа ионны сист мы


К защите допустить:

Заведующий кафедрой Цехановский В.В.



ЫПУ АЯ

АЛИФИ А ИО АЯ АБОТА

МАГИ Т А


Тема:
Автоматизация учета рабочего времени с использованием
альтернативных источников информации.


Студент




Страхов И.П.



подпись


Фамилия И.О.

Руководитель

к.т.н., доцент



Шилов Н.Г.


Уч. степень, уч. звание)

подпись


Фамилия И.О.

Консультанты

д.э.н., профессор



Маслова Т.Д
.


Уч. степень, уч. звание)

подпись


Фамилия И.О.

Нормоконтроль




Кор
о
бкин

В.П.


Уч. степень, уч. звание)

подпись


Фамилия И.О.

Антиплагиат

к
.т.н., доцент



Назаренко

Н.А.


Уч. степень, уч. звание)

подпись


Фамилия И.О.



Санкт
-
Петербург

2017

2


ЗАДАНИЕ

НА ВЫПУСКНУЮ КВАЛИФИ
КАЦИОННУЮ РАБОТУ



Утверждаю


Зав. кафедрой
ИС


____________
Цехановский В.В.


©___ª______________20___ г.


Студент ка)

Страхов И.П.


Группа

1374

Тема работы:
Автоматизация учета рабочего времени с использованием ал
ь-
тернативных источников информации.

Место выполнения ВКР:
СПбГЭТУ

Исходные данные технические требования):

-

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

-

учет пересечения сотрудником пункта контроля пропуска

-

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

Содержание ВКР:

-

обз
ор существующих решений для контроля рабочего времени

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

-
разработка программного кода приложения.

Перечень отчетных материалов: пояснительная записка,
презентация

Дополнительные разделы:
составление бизнес
-
плана по коммерциализации
результатов НИР магистранта.


Дата выдачи задания

Дата представления ВКР к защите

©___ª______________20___ г.

©___ª______________20___ г.

Студент


Страхов И.П.

Руководитель


Иванов И.И.

Уч. степень, уч. звание)



3


КАЛЕНДАРНЫЙ ПЛАН ВЫП
ОЛНЕНИЯ

ВЫПУСКНОЙ КВАЛИФИКАЦ
ИОННОЙ РАБОТЫ



Утверждаю


Зав. кафедрой ИС


____________ Цехановский В.В.


©___ª______________20___ г.


Студент

Страхов И.П.


Группа

1374

Тема работы: Автоматизация учета рабочего времени с использованием ал
ь-
тернативных источников

информации



п/п

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

Срок в
ы-
полнения

1

Изучение литературы и информационных ресурсов по
предметной области

20
.0
2



28
.0
2

2

Анализ существующих решений

0
1
.0
3



0
7
.0
3

3

Выбор инструментов разработки

0
8
.0
3


11
.0
3

4

Проектирование
системы

12
.0
3



03
.0
4

5

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

0
4
.0
4



0
2
.0
5

6

Оформление пояснительной записки

0
3
.0
5



17
.0
5


Студент


Страхов И.П.

Руководитель


Шилов Н.Г.

Уч. степень, уч. звание)





4


Р
еферат



Пояснительная записка содержит
8
0

стр.,
10

рис.,
11

табл.,
11

ист.,
4

прил.


Ключевые слова: автоматизация учета времени, клиент
-
сервер, импорт
данных, веб
-
сервис,
spring

boot
, объектно
-
реляционное отображение, реляц
и-
онная база данных.

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

Цель работы


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

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


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







5


ABSTRACT


The object of research of this master thesis is the time tracking system of
employees working hours.

The main goal of this work is development of time tracking system and i
m-
plementation the user interface to access it.

In this article, the concepts of the development of time tracking system are
considered. The architectural solutions for application
development are chosen and
the basic principles of the system construction are given.





















6


Содержание


Определения, обозначения и сокращения

................................
.............................

8

Введение

................................
................................
................................
...................

9

Глава 1.


Подходы к решению задачи учета рабочего времени.
...................

10

1.1

Методы учета рабочего времени.

................................
............................

10

1.2

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

....

14

1.3

Обзор существующих решений систем учета рабочего времени.

.......

16

Вывод
.

................................
................................
................................
..................

27

Глава 2.

Проектирование системы учета рабочего времени.

........................

28

2.1

Основные требования к разработанной системе.

................................
..

28

2.2

Архитектура системы. Клиент
-
сервер.

................................
...................

39

2.3

Пользовательский интерфейс.

................................
................................
.

45

Вывод.

................................
................................
................................
..................

46

Глава 3.

Разработка программного кода приложения.

................................
..

48

3.1

Автоматизация сборки приложения.

................................
.......................

48

3.2

Разработка серверной части системы.

................................
....................

53

3.3

Разработка клиентской части приложения.

................................
............

59

3.4

Импорт данных из внешней системы пункта пропуска.

.......................

62

Вывод.

................................
................................
................................
..................

64

Глава 4.

Составление бизнес
-
плана по коммерциализации результатов НИР
магистранта.

................................
................................
................................
...........

65

4.1

Описание продукта.

................................
................................
..................

65

4.2

Ан
ализ рынка сбыта продукции.

................................
.............................

66

4.3

Анализ альтернативных систем учета рабочего времени.

....................

66

7


4.4

Определение трудоемкости работ.

................................
..........................

68

4.5

Расчет заработной платы и отчислений на социальные нужды.

..........

69

4.6

Расчет затрат на материалы и у
слуги сторонних организаций.

...........

72

4.7

Определение величины амортизационных отчислений используемых
основных средств.

................................
................................
...............................

73

4.8

Определение накладных расходов.

................................
.........................

75

4.9

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

................................
................................
................................
...............

75

4.10

Рентабельность.

................................
................................
.........................

76

Вывод:

................................
................................
................................
..................

76

Заключение

................................
................................
................................
.............

78

Список использованных источников

................................
................................
...

79

Приложение А.
Pom
-
файл проекта
-
сервера.

................................
.......................

81

Приложение Б. Файл сборки
gulpfile
.
js

................................
...............................

84

Приложение В.
JPA

конфигурация класса
Employee
................................
.........

85

Приложение Г. Программа
-
клиент на языке
C
#

................................
.................

86












8


О
пределения, обозначения и сокращения


В настоящей пояснительной записке применяют следующие термины с
соответствующими определениями:

AD


active directory

API
-

application
programming interface

CRUD


операции

create, read, update, delete

JDBC
-
j
ava d
ata
b
ase
c
onnectivity

JPA


java p
ersistence
API

JSON


javascript object notation

REST


стиль

архитектуры

веб
-
сервисов
(
r
epresentational state t
ransfer)

БД


база данных

СУБД


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

СУРВ


система учета рабочего времени

ОС


операционная система
















9



Введение


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

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

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

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






10


Глава
1
.


Подходы к решению задачи учета рабочего времени.


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


1.1

Методы учета рабочего времени.

Сегодня новые технологии позволяют системам учета рабочего врем
е-
ни и присутствия получать более точ
ные данные о действиях сотрудников,
обеспечивая
[1]
:



регистрировать записи о том, когда сотрудники приходят и уходят



регистрацию временного отсутствия сотрудников



данные для отдела кадров для проверки посещаемости сотрудников



систем
у

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



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


1.1.1

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

К

традиционным источника
м

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



11


1.1.1.1

Информация из журналов учета.

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

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

контроля

пропуска. К тому же многие подобные сист
е-
мы учитывают только факты первого и последнего пересечения сотруднико
м

пропускного пункта.


1.1.1.2

Информация о времени работы компьютера
.

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

посещает.


1.1.1.3

Программы планирования задач
.

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


большей степени данные приложения служат для целей стратегического м
е-
неджмен
та
[2]
.


1.1.2

Новейшие технологии контроля времени и управления доступом.

Некоторые из новейших технологий, использующие
ся

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


1.1.2.1

Применение технологии штрих
-
кодов.

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

ее

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




1.1.2.2

Радиочастотная идентификация. RFID.

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


RFID, радиочастота обнаруживается, и сотрудник получает доступ в здание,
а его присутствие фиксируется в базе данных
[3]
. Человеку не нужно

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


1.1.2.3

Биометрическое отслеживание времени и посещения.

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

как для повышения точн
о-
сти, так и для повышения безопасности.


1.1.2.3.1

Идентификация по отпечаткам пальцев.

Технология отпечатков пальцев
существует

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

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


1.1.2.3.2

Применение систем распознавания лиц.

Технология распознавания лиц
-

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


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

стоят перед каме
рой.


1.2

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

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


1.2.1

Основные задачи.

Система учета рабочего времени

далее СУРВ) решает следующие з
а-
дачи
[1]
:



определяет,

в каких сайтах и программах работал пользователь на ПК;



категоризует затраченное на эти активности время как продуктивное
или непродуктивное;



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


1.2.2

Составные части
системы

учета рабочего времени.

СУРВ состоит из следующих компонентов
[2]
:



Агент



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

как запрет на открытие определенны
х

веб
-
15


сайтов или просьбу указать
,

чем сотрудник занимался во время простоя
ПК.



Сервер



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



База данных



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

серверу для генерации отчетов. Для ускорения форми
рования отчётов
данные периодически пресуммируются. Обычно используются класс
и-
ческие SQL RDBMS, но в редких случаях разработчики эксперимент
и-
руют с NoSQL обычно MongoDB).



Административная консоль.


1.2.3

Как осуществляется учет рабочего времени
.

Системы к
онтроля сотрудников делятся на три основных типа
[2]
. Пе
р-
вые


делают основной упор на записи действий персонала за компьютером
на видео, онлайн
-
наблюдение и контроль нарушений. Безусловным плюсом
такого подход
а

является тот факт, что от видео спрятаться не
возможно. М
и-
нус


для хранения видео необхо
димо достаточное место на диске.

Другие


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

поиска по полученным

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

письмам, сообщениям

и прочему

можно найти возможные
нарушения сотрудника. Минус


очень тяжело проанализир
овать большой
объем информации.

Третья группа



системы УРВ




сохраняют минимум да
н-
ных:

только посещенные сайты

и запущенные программы. Такого рода пр
о-
граммы делят активность на продуктивную, непродуктивную,

нейтральную и
16


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

Плюс подобных

систем в их простоте и малом объеме
данных для хр
а-
нения и передачи. Поскольку конфиденциальная информация

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

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


1
.3

Обзор существующих решений систем учета рабочего времени.

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

Проведем анализ, используя следующие критерии:



Принцип работы
.

Общее описание работы, и специфика собираемых
данных.



Гибкий график
.

В
озможность гибкого графика. Например, пришел с 8
до 10:30 ушел с 17 до 20, обед 30
-
40 мин в любое время.



Заявки на отпуск, отгул. Табель
.

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



Наличи
е API
.



Отчеты
.

Какие есть отчеты и насколько они информативны.



ОС и БД

с которой работает программа.

17




Интеграция с
AD
.

Как настраивается, нужно ли пользователям вводить
пароль, понимает ли система
,

какой пользователь работает на компь
ю-
тере.



Настройки
.

Что н
еобходимо настроить для начала работы системы.



Многопользовательский, много компьютерный режим
.

Умеет ли с
и-
стема распознавать работу нескольких пользователей на одном комп
ь-
ютере

-

терминальном сервере или одного пользователя на нескольких
компьютерах.



Рабо
та через интернет сети
.

Информация про публикацию и шифр
о-
вание соединения при передаче данных между клиентом и сервером.



Доступ к статистике
.

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



Для наблюдаемого
.

Как пользователь может определить, что клиент
установлен на компьютере.


1.3.1

Система учета рабочего времени Kickidler.

Принцип работы
.

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

Гибкий график
.

В программе отсутствует возможность задавать график.

Заявки на отпуск отгул. Табель
.

Заявки и отчеты для бухгалтерии о
т-
сутствуют.


Наличие API
.

Нет.

18


Отчеты
.

Отчеты отображают наиболее используемые программы и
сайты. Отчеты не

информативные, они не рассчитаны на контроль графика
работы сотрудников. В отчетах присутствует фильтрация. При просмотре
мониторов сотрудников на экране одновременно помещается до 16 монит
о-
ров, что будет проблемой при необходимости мониторинга работы сот
ру
д-
ников в реальном времени в компаниях с большим штатом.

ОС и БД
.

Сервер Kickidler работает под ОС Windows и с БД
PostgreSQL. Есть версия сервера под Linux, но в ней реализован ограниче
н-
ный функционал.


Интеграция с
AD
.

Нет.

Настройки
.

Для работы системы
необходимо установить сервер и
агенты на компьютеры пользователей. Для доступа к записанным видео и
с-
пользуется отдельная программа ©Viewerª, которую необходимо установить
сотрудникам, которые будут следить за собранными данными. Если система
разворачиваетс
я локально, то потребуется локальный сервер лицензиров
а-
ния.

Многопользовательский, много компьютерный режим
.

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

Работа через интернет сети
.

Для работы программы необходим д
о-
ступ к my.kic
kidler.com, через который происходит синхронизация сервера

и
проверка лицензии. При локальной установке данный адрес должен вести на
локальный сервер лицензирования. Заявлена поддержка ssl.


Доступ к статистике
.

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

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

Для наблюдаемого
.

Наличие агента можно определить через

диспетчер
задач по процессам
grabber
.
exe
,
grabberAgent
.
exe
,
grabberSubAgent
.
exe
. Путь
по умолчанию
C
:
\
Program

Files

(
x
86)
\
TeleLinkSoftHelper
.

19


1.3.2

Система

учета

рабочего

времени

StaffCop
.

Принцип работы
.

На машины сотрудников устанавливается скрытый
агент, который собирает информацию о
б

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

Гибкий график
.

Отсутствует возможность задать график.

Заявки на отпуск отгул. Табель
.

Заявки и отчеты для бухгалтерии о
т-
сутствуют.


Наличие API
.

Нет.

Отчеты
.

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

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

ОС и БД
.

Сервер работает под ОС Windows, использует простую фа
й-
ловую БД.

Интеграция с
AD
.

Нет.

Настройки
.

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

адреса машин, с которых
необходимо собирать данные.

Многопользовательский, много компьютерный режим
.

Статистика с
о-
бирается по компьютеру.

20


Работа через интернет сети
.

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

Доступ к статистике
.

Статистика отображается в приложении серв
е-
ра. Доступа через веб
-
интерфейс нет. Предоставить сотрудникам доступ к
статистике невозможно.

Для наблюдае
мого
.

Наличие агента можно определить через диспетчер
задач по запущенной службе Scheduler и процессу SchedulerSVC.exe. Путь
установки агента C:
\
Program Files (x86)
\
StaffCop.


1.3.3

Система учета рабочего времени ManicTime
.


Принцип работы
.

 Установленный
агент собирает данные о времени
работы за ПК и используемых программах и сайтах.


Гибкий график
.

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


Заявки на отпуск отгул. Табель
.

Заявок н
ет, но есть метки
,

которыми
можно отмечать свое время. С их помощью можно отмечать отгулы и т.д.
Есть отчет ©Посещаемостиª, отображающий количество отработанных дней
сотрудника.


Наличие API
.

Для доступа и манипулирования данными сервера есть
возможность
использовать HTTP API.


Отчеты
.

Отчетов не много. Они поделены на два типа: время работы
начало/конец, переработка…) и продуктивность используемые веб сайты,
программы, документы, статистика продуктивности).


ОС и БД
.

Сервер работает под Windows. По умол
чанию используется
SQLite. Для большого числа пользователей больше 5


рекомендация разр
а-
ботчиков), необходимо использовать PostgreSQL или Microsoft SQL Server.


Интеграция с
AD
.

Можно получить список пользователей из
AD
. Это
позволить не вбивать вручную
имена пользователей.


21


Настройки
.

При установке сервера необходимо выбрать
,

с какой БД
работать. СУБД должна быть настроена до установки сервера кроме SQLite).
В агенте необходимо указать адрес
сервера,

куда отправлять статистику.


Многопользовательский,
много компьютерный режим
.

Система иде
н-
тифицирует пользователя по имени компьютеру и логину.


Работа через интернет сети
.

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


Доступ к статистике
.

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


Для наблюдаемого
.

В обычном режиме агент виден в трее. Если агент в
скрытом режиме определить его наличие можно через диспетчер задач. Пр
о-
цесс называется ManicTime Client, станд
артный путь установки C:
\
Program
Files (x86)
\
ManicTime.


1.3.4

Система учета рабочего времени
.

Принцип работы
.

 SkypeTime получает данные о статусе сотрудников с
сервера Skype For Business, поэтому установка агентов на машины сотрудн
и-
ков не требу
ется. Из
-
за такой концепции количество собираемых данных г
о-
раздо меньше
,

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


Гибкий график
.

В графике указывается время начала и конца рабочего
дня и
количество часов
,

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


22


Заявки на отпуск отгул. Табел
ь
.

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


Наличие API
.

Нет


Отчеты
.

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

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


ОС и БД
.

Программа работает на

ОС Windows и с базой данных
MySQL.


Интеграция с
AD
.

Так как сервер Skype For Business имеет интеграцию
с
AD
, отдельная интеграция не требуется.


Настройки
.

Для начала работы необходимо установить веб сервер,
установить SQL Server
, предоставить доступ на чтение к БД Skype For
Business, развернуть базу данных, предоставить доступ к базе данных и
настроить публикации.


Многопользовательский, много компьютерный режим
.

Система расп
о-
знает пользователей по логинам, по которым производиться вход в Skype For
Business. Информация по компьютерам
,

с которых был произведен вход
,

б
у-
дет доступна в статистике.


Работа через интернет сети
.

При настройке публикации можно
включить использование SS
L.


Доступ к статистике
.

Есть возможность предоставить сотрудникам
доступ к статистике через веб
-
интерфейс. Можно назначать менеджеров о
т-
делов.

Для наблюдаемого
.

На компьютеры сотрудников не устанавливается
клиентское приложение, из
-
за чего невозможно опре
делить используется ли


23


1.3.5

Система учета рабочего времени Yaware.TimeTracker
.

Принцип работы
.

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


Гибкий график
.

Можно установить время начала и конца рабочего дня,
и время, которое необходимо отработать, что бы день был засчитан. Пр
о-
грамма поддерживает два варианта графика. ©Стандартная неделяª


фи
к-
сированные рабочие дни. ©Работа по сменамª


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


Заявки на отпуск отгул. Табель
.

Заявок нет, менеджер сам выставляет
события отпуск, больничный), указывать можно как конкретного человека,
так и отдел. Для отчета пере
д бухгалтерией в программе предусмотрены о
т-
четы: ©Табель учета рабочего времениª, ©Отчет по посещаемостиª.


Наличие API
.

Есть API позволяющее самостоятельно реализовать д
о-
ступ к собранной статистике
,

используя HTTP запросы.


Отчеты
.

В программе много отчет
ов
:

как по времени работы, так и по
эффективности. Часть отчетов отображают схожую информацию. Есть во
з-
можность отображать отчет за определенный период. Данные из отчетов
можно экспортировать в XLS, CSV, PDF.


ОС и БД
.

Определить
,

на какой ОС и с какой БД
работает локальный
сервер
,

не удалось.


Интеграция с
AD
.

Нет.


Настройки
.

Для облачной версии достаточно установить клиент. И
н-
формацию по настройке локальной версии получить не удалось.


Многопользовательский, много компьютерный режим
.

Yaware иде
н-
тифицирует пользователя по логину и имени компьютера. Если изменить л
о-
24


гин или пересесть за другую машину, это будет распознано как новый пол
ь-
зователь. Пользователей можно объединять.


Работа через интернет сети
.

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


Доступ к статистике
.

Есть возможность предоставить сотру
днику д
о-
ступ к его статистике. Краткую статистику можно узнать из агента, если он
не в скрытом режиме. Более подробная статистика отображается в веб и
н-
терфейсе. Есть возможность назначить менеджера отдела.

Для наблюдаемого
.

По умолчанию агент отображается
в трее, на серв
е-
ре есть опция, позволяющая скрыть агент. В таком случае наличие агента
можно узнать из диспетчера задач по процессам YaService.exe и
YaUpdate.exe и службе Yaware.TimeTracker Collector Service.



1.3.6

Система учета рабочего времени Crocotim
e.

Принцип работы
.

 Агент собирает данные о времени за компьютером
,

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

эффективные и не
эффективные. Есть возможность включить периодическое снятие скринш
о-
тов.


Гибкий график
.

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


Заявки на отпуск отгул
.
Табель
.

Заявок нет. Менеджер может устана
в-
ливать причину отсутствия: командировка, больничный, отгул, отпуск, пр
о-
гул. По умолчания при отсутствии программа ставит ©прогулª. Для бухга
л-
терии есть отчет ©Табельª, в котором указанно
,

ка
кие дни отработаны и
сколько часов.


25


Наличие API
.

Присутствует Web API, позволяющее взаимодействовать
с сервером с помощью HTTP запросов.


Отчеты
.

Отчеты предоставляют информацию по продуктивности
р
а-
боты,

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


ОС и БД
.

Сервер работает на ОС Windows. По умолчанию используется
БД SQLite
, но есть возможность перейти на PostgreSQL. Миграция в обра
т-
ную сторону не возможна.


Интеграция с
AD
.

Есть возможность подгрузить пользователей из AD.
Это избавит администратора от необходимости вручную вбивать данные с
о-
трудника ФИО, email
…) и структуру отделов в систему. Так же позволит
пользователям входить в систему мониторинга по доменным паролям и
с-
пользуя авторизацию Kerberos. Выгружать можно не всю структуру, а только
часть.


Настройки
.

Для настройки достаточно установить сервер и аге
нты.


Много пользовательский много компьютерный режим
.

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


Работа через интернет сети
.

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


Доступ к статистике
.

Есть возможность предоставить доступ к стат
и-
стике пользователям для самоконтроля. Статистика доступна через веб
-
интерфейс. Можно предоставлять доступ к статистике других сотрудн
и-
ков отделов).


26


Для наблюдаемого
.

На
личие агента можно определить через диспетчер
задач по процессу

agent
_
service
64.
exe

и службе
CrocoTime

Agent
. По умолч
а-
нию путь агента
C
:
\
Program

Files
\
CrocoTime

Agent
.



1.3.7

Система учета рабочего времени TimeCamp
.

Принцип работы
.

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


Гибкий график
.

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

активности.


Заявки на отпуск отгул. Табель.

Заявок нет, менеджер может изм
енить
тип дня отпуск, больничный, деловая поездка…) определенного сотрудника.
Есть отчет ©Посещаемостьª, в котором отображаются данные о времени р
а-
боты сотрудника по каждому дню в месяце.


Наличие API
.

Есть API, взаимодействие с сервером происходит через
HTTP запросы. Есть множество аддонов
,

позволяющих синхронизировать
данные с различными календарями, и более подробное отслеживание акти
в-
ности в приложениях например, в Visual Studio).


Отчеты
.

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


ОС и БД
.

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


Интеграция с
AD
.

Нет.


27


Настройки
.

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


Многопользовательский, много компьютерный р
е-
жим
.

Автоматического определения пользователей нет. При установке аге
н-
та необходимо вве
сти учетные данные от аккаунта на timecamp.com.


Работа через интернет сети
.

Для отправки данных на сервер испол
ь-
зуется SSL. Так как агент сам отправляет данные на сервер, NAT не влияет на
работу приложения.


Доступ к статистике
.

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


Для наблюдаемого
.

Агент отображается в трее. Так же определить
наличие агента можно определить через диспетчер задач по процессу
timecamp.exe
и reshost.exe. По умолчанию путь агента
C:
\
Users
\
UserName
\
AppData
\
Local
\
TimeCamp.



Вывод
.

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

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





28


Глава
2.

Проектирование системы учета рабочего времени.


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

и сопровождения системы
[4]
.


2.1

Основные требования к
разработанной

системе.

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

к системе учета времени,
разработанной

в рамках данной работы:



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



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

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



Разработка механизмов разрешения противоречий данных о рабочем
времени



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



Разработка универсального
API
, позволяющая сторон
ним системам з
а-
прашивать информацию о рабочем времени сотрудников.




29


2.1.1

Описание пользовательских сценариев.

Основная цель создания любой программной системы
-

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



Для того
,

чтобы более точно понять как должна работать система,
используется описание функциональности системы через варианты и
спол
ь-
зования Use Case или прецеденты). Варианты использования
-

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

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


управляют всем процессом
разработки. Все основные виды
деятельности,

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

Диаграмма вариантов использования состоит из актеров,
для которых
система производит действие и собственно действия Use Case, которое оп
и-
сывает то, что актер хочет получить от системы.

Ответы на следующие вопросы позволят определить актеров, взаим
о-
действующих с системой:



кто взаимодействует с системой или ис
пользует систему;



кто передает или принимает информацию в/из системы;



кто является внешним по отношению к системе.

30


Каждый вариант использования показывает, как конкретный актер и
с-
пользует систему и в дальнейшем расширяется диаграммами состояний и п
о-
следова
тельности действий.


Рисунок 1
-

диаграмма вариантов использования.

Приведенная на рисунке

1

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


2.1.1.1

Сценарии сотрудника.

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

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

системы. Они п
риведены в таблице 1 и таблице 2.


31


Таблица 1



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

система

Действующие

лица

Компьютер сотрудника, Система

Цель

Добавить запись о прибытии сотрудника на рабочее место

Предусловие

Для сотрудника отсутствуют
©незакрытыеª записи в базе
данных все записи имеют время начала и окончания прису
т-
ствия)

Успешный

сценарий:


1.Сотрудник включает компьютер.

2.Программа клиент отправляет информацию о включении компьютера на
сервер.

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

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

Результат

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


Таблица 2

-

сценарий использования сотрудник
-

система

Действующие

лица

Сотрудник, Система

Цели

Просмотреть данные журнала рабочего времени





32


Продолжение таблицы 2.

Успешный

сценарий:

1.Сотрудник через
web
-
интерфейс делает запрос к системе.

2.Система, по
запрашиваемым параметрам делает запрос в базу.

3.Система выдает сотрудник ответ с информацией о времени его прису
т-
ствия на работе.

Результат

Сотрудник видит детализацию своего рабочего времени.

Расширения:



Сотрудник хочет внести изменения в журнал
рабочего вр
е-
мени.

Сотрудник вносит информацию о своем рабочем времени
через
web
-
интерфейс.

Результат: информация сохранена в базе данных.


2.1.1.2

Сценарии
администратора.

Основная функция администратора системы учета рабочего времени


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

Сц
е-
нарий для данного вариант приведен в таблице 3.

Таблица 3
-

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

система

Действующие

лица

Администратор, Система

Цель

Редактирование сущностей базы данных.



33


Продолжение таблицы 3

Предусловие

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

Успешный

сценарий:


1.Администратор через
web
-
интерфейс заходит на
страницу редактирования
данных.

2.Делается запрос на редактирование данных к серверу.

3.Сервер обрабатывает запрос, делая необходимые изменения в базе данных.

4.Сервер возвращает ответ с актуальной информацией из БД.

Результат

В базе данных сохраняются
изменения, произведенные адм
и-
нистратором.


2.1
.1.3 Сценарии сторонних систем.

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

на основе
REST
-
архитектуры, которая позволяет делать запросы к системе на
основе
HTTP

протокола и получать ответы в JSON формате. В связи с этим в
разработанной

системе можно выделить еще одно действующее лицо


ст
о-
ронняя информационная система.

Сценарий взаимодействия внешних систем
с разработанной системой учета рабочего времени приведен в таблице 4.

Таблица 4
-

сценарий использования с
торонняя инф
ормационная система

-

с
истема учета времени

Действующие

лица

Сторонняя информационная система, Система учета времени

34


Продолжение таблицы 4.

Цель

Запросить информацию о рабочем времени сотрудников

Предусловие

Имеется доступ к системе учета времени по
HTTP

проток
о-
лу.

Успешный

сценарий:

Сторонняя информационная система делает
HTTP

з
а-
прос в систему учета

рабочего времени.

СУРВ обрабатывает запрос, делает запрос в базу данных, формирует ответ.

Ответ отправляется системе, которая сделала запрос

Результат

Сторонняя информационная система получила актуальные и
корректные данные в соответствии с запрашиваемыми пар
а-
метрами.


2.1.2

Мо
делирование предметной области.

В

основе проектирования ИС лежит

моделирование предметной обла
-
сти.

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

моделью предметной

области

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


быть адекватной этой области
[5]
.

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


и высоким затратам на последующее перепроек
тирование системы. Всле
д-
ствие этого все современные технологии проектирования ИС основываются
на использовании методологии моде
лирования предметной области
[4]
.

К моделям предметных областей предъ
являются следующие требо
-
вания
[5]
:



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

предметной области;



понятность для заказчиков и разработчиков на основе применения

графических средств отображения модели;



реализуемость, подразумевающая наличие

средств физической реал
и-
зации модели предметной области в ИС;



обеспечение оценки эффективности реализации модели предметной
области
,

на основе определенных методов и вычисляемых показателей.

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

которая отражает структурный и оценочный аспекты фун
к-
ционирования предметной области.

Выделим следующие сущности в
разработанной

информационной с
и-
стеме:



Position



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

имеет
следующие поля:



fullName


полное название должности



shortName



краткое название должности, в общем случае являе
т-
ся аббревиатурой.Например, должность с полем
fullName

©Ста
р-
ший научный сотрудникª может иметь поле
shortName

©с.н.с.ª.



Employee



класс, содержащий информацию о сотруднике. Связан а
г-
регацией один ко многи
м с классом
positon



каждый сотрудник имеет
36


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



name



имя сотрудника. Фактически, это полное имя сотрудника,
так как в рамках
разработанной

системы нет необходимости сп
е-
цифицировать составные части им
ени.



position



должность сотрудника. Благодаря этому полю появл
я-
ется возможность классификации сотрудников и их структуриз
а-
ции.



active



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



ip



ip
-
адрес компьютера сотрудника. Является одним из идент
и-
фикаторов сотрудника в системе. Благодаря ему упрощается с
и-
стема авторизации


при входящем запросе определяется
ip
-
адресс, с которого сделан запрос и, таки
м образом, сотрудник
идентифицируется.



employeeReason



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



Attendance



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


многим с классом
Employee



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



employee



сотрудник, которому соответствует данный объект
присутствия на рабочем месте.



start



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



finish



время и дата окончания работы на персональном компь
ю-
тере



comment



комментарий для соответствующей записи. Возмо
ж-
ные варианты: ©включение компьютераª
-

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



AbsenceReason



класс, определяющий причину отсутствия сотрудника
на рабочем месте. Имеет ассоциацию мно
гие ко многим с классом
E
m-
ployee



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



name

-

назван
ие причины отсутствия. Например: ©отпускª,
©больничныйª, ©преподавательская деятельностьª.



fullDay



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

38




Absence



класс, представляющий информацию о временя отсутствия
сотрудника в офисе. Связан композицией один ко многим с классом
AbsenceReason



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

с конкретным временем отсутствия. Также данный класс св
я-
зан композицией один ко многим с классом
employee



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



employee



сотрудник, которому соответствует данный объект
отсутствия на рабочем месте.



reason



причина, по которой сотрудник отсутствовал в данное
время.



start



время и дата ухода сотрудника из офиса.



finish



время и дата
возвращения сотрудника в офис.

Диаграмм
а

классов, соответствующая приведенному выше описанию
представлена на рисунке

2
.


Рисунок 2


объектная модель данных предметной области


39


2.2

Архитектура системы. Клиент
-
сервер.

В соответствии с рассмотренными ранее

концептуальными требован
и-
ями к системе учета рабочего времени, наиболее подходящей архитектурой
для разработки приложения является архитектура клиент
-
сервер. Использ
о-
вание данного архитектурного подхода даст ряд преимуществ
[6]
:



Общая серверная логика при
обработке запросов



Общая база данных, предоставляемая в качестве разделяе
мого
ресу
р-
са



Независимость клиентов друг от друга

Рассмотрим общую схему взаимодействия в рамках
разработанной

с
и-
стемы

представленной на рисунке 3
.


Рисунок 3


архитектура системы

На рисунке

3

приведены основные структурные части системы ко
н-
троля учета рабочего времени:



Сервер базы данных,

на котором непосредственно находится база да
н-
ных и который обеспечивает запросы к ней со стороны сервера прил
о-
жения и ответы на них.

40




Сервер прило
жения


ядро
разработанной

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

информационно
й

системы.



Компьютеры
-
клиенты


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



Сервер системы пропуска


является
third
-
party

software
. Предоставляет
информацию о пересечении сотрудников пункта пропуска.


2.2.1

Проектирование серверной части.

Сервер приложения


ядро
разработанной

системы учета рабочего вр
е-
мени. Основные функции сервера приложения
[6]
:



Обеспечивает непрерывную работу системы,



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

o

Принимает и обрабатывает запросы от клиентских программ

o

Делает запросы в базу дан
ных

o

Обеспечивает синхронизацию
разработанной

системы с сервером
пропускной системы



реализует бизнес
-
логику приложения


2.2.1.1

Синхронизация данных с сервером пропускной системы.

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


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

на диаграмме последовательности

на рисунке 4
:


Рисунок 4


диаграмма
последовательности импорта данных.

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

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

42


2.2.1.2

Обеспече
ние доступа сторонним системам.

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

универсального
API

на основе
REST

архитектуры.

REST



архитектурный стиль

взаимодействия компонентов распред
е-
лённого приложения в

сети
. REST представляет собой согласованный набор
ограничений, учитываемых при проектировании распределё
н-
ной

гипермедиа
-
системы
[7]
. В общем случае под
REST

понимается взаим
о-
действие по
http

протоколу с использованием стандартных методов:
,
POST
,
PUT
,
DE
LETE
. Для передачи данных обычно используется формат
JSON
.

Общая схема взаимодействия сторонней системы с
разработанной

с
и-
стемой контроля учета рабочего времени представлена на диаграмме

на р
и-
сунке 5
:


Рисунок 5


диаграмма последовательности взаимодействия с внешней
системой

43


Система
-
клиент инициирует запрос данн
ых и делает
http

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


2.2.2

Проектирование клиентской части системы.

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


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

на рисунке 6.


Рисунок 6


диаграмма последовательности
взаимодействия клиента и
сервера

В момент включение компьютера происходит автозагрузка программы
-
клиента. При старте программы она отправляет на сервер запрос о том, что
44


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


2.2.3

Модель хранения данных.

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

Целью построения логической модели является получение граф
и-
ческого представления логической структуры исследуемой предметной
области
[4]
.

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

Сущности описывают объекты, являющиеся предметом деятельн
о-
сти предметной области, и субъекты, осуществляющие деятельность в
рамках предметной области. Свойс
тва объектов и субъектов реального
мира описываются с помощью атрибутов.

Взаимоотношения между сущностями иллюстрируются с пом
о-
щью связей. Правила и ограничения взаимоотношений описываются с
45


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

Схема логической модели базы данных приведена на рисунке

7.


Рисунок 7
-

с
хема логической модели базы данных


2.3

Пользовательский интерфейс.

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

Функциональность

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

Эстетичный внешний вид

самого приложения и спо
соба его предста
в-
ления вплоть до упаковки) позволяет сформировать у потребителя полож
и-
46


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

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

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

системе
осуществляетс
я

с помощью браузера через
http

протокол.

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


страница должна быть разбита на несколько независимых функциональных
компонентов.


Вывод.

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

качестве архитектуры
разраб
о-
танного

приложения клиент
-
серверн
ую

архитектур
у
. Она позволила реализ
о-
вать распределенное приложение с независимым доступом к общим ресурсам


реляционной базе данных.
Также были рас
смотрены основные пользов
а-
47


тельские сценарии, доступные системы
.

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


























48


Глава
3.

Разработка программного кода приложения.


В зависимости от вида, масштабов и потребностей проекта определяе
т-
ся порядок разработки. Он может несколько отличаться для

разработки м
о-
бильных приложений
,

встроенного ПО
,

решений для автоматизации

и

баз

данных
, но общая последовательность действий для создания ПО униве
р-
сальна

и приведена на рисунке 8.


Рисунок 8


последовательность разработки П
О

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

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


3.1

Автоматизация сборки приложения.

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


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



Улучшение качества продукта



Ускорение процесса компиляции и линковки



Избавление от излишних действий



Минимизация ©плохих некорректных) сборокª



Избавление от п
ривязки к конкретному человеку



Ведение истории сборок и релизов для разбора выпусков



Экономия времени


3.1.1

Применение системы сборки
Maven

для сборки
j
ava
-
приложения.

Так как основным языком разработки приложения в рамках данной в
ы-
пускной квалификационно
й работы является
j
ava
, то систему сборки необх
о-
димо выбрать среди доступных для данной платформы. Широко распростр
а-
ненными системами сборки для
j
ava

являются
ant
,
graddle

и
maven
.

Ant

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

j
ava



JRE
. Отказ от
использования команд

операционной системы

и формат

XML

обеспечивают
переносимость сценариев.

Управление процессом сборки происходит посредством

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

процедурами

в языках программирования и содержат вызовы
команд
-
заданий
Tasks
).

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

50


Между целями могут быть определены зависимости



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

Типичными примерами целей являются

clean

удаление промежуто
ч-
ных файлов),

compile

(
компиляция

всех классов),

deploy

развёртывание пр
и-
ложения на сервере). Конкретный набор целей и их взаимосвязи зависят
от
специфики проекта.

Gradle



система автоматической сборки
,
построенная на принц
и-
пах

Apache Ant

и

Apache Maven
, но использующая язык
Groovy

для описания
конфигурации

вместо традиционной

XML
-
образной формы представления
конфигурации проекта.

В отличие от

Apache Maven
, основанного на кон
цепции жизненного
цикла проекта, и

Apache Ant
, в котором порядок выполнения задач определ
я-
ется отношениями зависимости, Gradle использует

направленный ациклич
е-
ский граф

для определения п
орядка выполнения задач.

В качестве системы сборки
j
ava
-
приложения системы учета рабочего
времени выбран
Maven
. Главной точкой входа для любого приложения, и
с-
пользующего систему сборки
Maven

является файл
pom
.
xml
. В нем в декл
а-
ративной форме описывается
жизненный цикл проекта, определяются зав
и-
симости от сторонних библиотек, которые
maven

автоматически подтягивает
и добавляет в итоговую сборку проекта.
Pom
-
файл с описанием зависимостей
и сборки серверной части
разработанной

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

1
.
В
нем описаны следующие зависимости:



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



Зависимости для модулей фреймворка
spring
(
Spring

data
,
Spring

boot
,
html
-
шаблонизатор
thymeleaf
)

51




Apache

httpclient
, который предоставляет
API

для выполненя
http
-
запросов из кода программы



Hibernate



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



Google

json



предоставляет
API

для работы с
json

файлами, а также
для сериализации и десериализации
java

объектов в
json

формат.

Также
Maven

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

Frontend

Plugin
, который запускает сборку фронтенд
-
части проекта, написа
н-
ную на языке
javascript
.


3.1.2

Применение системы сборки
Gulp

для сборки фронтенд
-
проекта.

В любом процессе разраб
отки приложения, содержащего
web
-
интерфейс необходимо создать некоторый набор файлов и папок, который
соответствует желаемой структуре, наиболее подходящей разрабатываемому
проекту. В этом случае необходимо заботитьс
я о сжатии и минимизации CSS
и
j
ava
s
crip
t, оптимизации изображений и других задач, которые необходимо
учитывать при оптимизации приложения.

Система сборки
Gulp

это потоковый сборщик проектов на языке
java
s-
cript
. Он использует потоки
node
.
js

для последовательного выполнения задач,
что значительно повышает его производительность по сравнению с такой с
и-
стемой сборки как
Grunt
. Вот некоторые задачи, которые
Gulp
помогает а
в-
томатизировать
[8]
:



минимизировать CSS;



минимизировать
j
ava
s
cript;



сжимать

и оптимизировать изображения;

52




компилировать файлы Sass,
Jsx
(
React
);



Собирать модуль
javascript
кода.

В рамках разработки системы учета рабочего времени, при разработке
пользовательского интерфейса использовался препроцессор
s
css

для оптим
и-
зации работы с к
аскадными таблицами стилей. Также, для разработки ко
м-
понентов интерфейса использовалась библиотека
ReactJS
, с помощью кот
о-
рой на
html
/
xml

подобном языке
jsx

были написаны
ui
-
компоненты. Но ни
s
css

ни
j
sx

напрямую не поддерживаются браузерами, поэтому предварител
ь-
но их необходимо скомпилировать:
s
css

в стандартный
css
-
файл,
j
sx

соотве
т-
ственно в
javascript

код. И именно в этом помогает система сборки
Gulp
. В
первую очередь необходимо определить зависимости
от сторонних библи
о-
тек. Для этого создается файл
package
.
json

в котором в
json
-
формате опис
ы-
ваются зависимости. Для данного проекта
package
.
json

имеет следующую
структуру:

{
"
name
"
:
"
worktime
"
,


"
version
"
:
"1.0.0"
,


"
author
"
:
"
Igor
"
,


"
devDependencies
"
: {


"
babel
-
preset
-
es
2015"
:
"^6.9.0"
,


"
babel
-
preset
-
react
"
:
"^6.5.0"
,


"
gulp
"
:
"^3.9.1"
,


"
gulp
-
babel
"
:
"^6.1.2"
,


"
gulp
-
clean
"
:
"^0.3.2"
,


"
gulp
-
concat
"
:
"^2.6.0"
,


"
gulp
-
rename
"
:
"^1.2.2"
,


"
gulp
-
sass
"
:
"^3.1.0"
,


"
gulp
-
uglify
"
:
"^1.5.4"
,


"
webpack
-
stream
"
:
"^3.2.0"
}}


53


В блоке
devDependencies перечисляются зависимости проекта:



babel
-
preset
-
es2015


плаги для компиляции
EcmaScript
6 кода в
Ecma
S-
cript
5 не все возможности 6 версии поддерживаются в современных
браузерах)



babel
-
preset
-
react


плагин для компиляции
Jsx
-
компонентов в
javascript
-
код



gulp
-
concat


плагин для склеивания разрозненных
css

и
javascript

фа
й-
лов в, соответственной, глобальный
css

и
javascript

файл



gulp
-
sass


плагин для преобразования
scss

кода в
css

Но основным файлом системы сборки
Gulp

является
gulpfile
.
js
. Он с
о-
держит описание шагов сборки в виде задач. Для того, чтобы выполнить ту
или иную задачу необходимо набрать команду
gulp

<имя_задачи>. Задачи
могут композироваться в единый поток и выполнятьс
я друг за другом
[
8]
. Для
автоматизации сборки фронтенд
-
части системы учета рабочего времени были
созданы задачи ‘
js
’, которая выполняет компиляцию
jsx

и
EcmaScript
6 кода в
javascript

код стандарта
EcmaScript
5 и задача ‘
default
’, которая запускает з
а-
дачу ‘
js
’, а после этого компилирует файлы
scss

в
css

и собирает их в единый
файл стилей. Файл
gulpfile
.
js

представлен в приложении

Б
.


3.2

Разработка серверной части системы.

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



Безотказность работы


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

54




Надежность соединения с базой данных
-

сервер должен иметь непр
е-
рывное соединение с базой данных и обеспечивать целостность данных
при их сохранении и передаче



Скорость работы


сервер должен обрабатывать запросы и отдавать р
е-
зультаты за разумное время.



Независимость от среды


сервер не должен зависеть от операционной
системы компьютера, на котором он установлен.

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

В качестве основы сервера выбран фреймворк
Spring

Boot
. Spring Boot
-

это фреймворк для быстрой разработки приложений на основе Spr
ing
Framework и его компонентов, входящих в
Spring Data
,
Spring Security

и др
у-
гие подпроекты. Spring Boot предоставляе
т огромное количество сконфиг
у-
рированных компонентов, что позволяет сократить время, затрачиваемое на
конфигурирование приложения и
сосредоточиться

непосредственно на ра
з-
работке, а так же упрощает работу с зависимостями. Некоторые возможн
о-
сти, предоставляемые Spring Boot
[9]
:



Создание полноценных Spring приложений



Встроенный Tomcat или Jetty не требуется установки WAR файлов)



Обеспечивает 'начальные' POMs для упрощения вашей Maven конф
и-
гурации



Автоматическая
конфигурация

Spring когда это во
зможно



Обеспечивает такими возможностями, как метрики, мониторинг сост
о-
яниями и расширенная конфигурация



Абсолютно

без генерации кода

и

без написания XML

конфигурация

Для инициализации
Spring

Boot

приложения в
pom

файл в качестве
проекта ©родителяª установ
лен ©spring
-
boot
-
starter
-
parentª. Точкой входа в
55


приложение является класс Application.
java
, отмеченный аннотацией
SpringBootApplication. Он содержит единственный метод
public static void
main в котором вызывается SpringApplication.
run
(Application.
class
).
По

выз
о-
ву метода
run

начинается инициализация контейнера
Spring
, сканируются п
а-
кеты проекта на наличие компонентов
Spring

Framework

и их инициализ
а-
ция
[9]
.


3.2.1

Использование
ORM

фреймворка
Hibernate
.

Hibernate



библиотека для языка
программирования

j
ava
, предназн
а-
ченная для решения задач объектно
-
реляционного отображения
ORM
).
Ц
е-
лью Hibernate

является освобождение разработчика от значительного

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

Библиотека не только решает задачу связи классов
j
ava с таблицами б
а-
зы данных и типов
данных
j
ava с типами данных

SQL
), но и также пред
о-
ставляет средства для автоматической генерации и обновления набора та
б-
лиц, построения запросов и обработки полученных. Hibernate обеспечивает
прозр
ачную поддержку сохранности данных
persistence
) для стандартных
j
ava
-
объектов.

Для создания объектно
-
реляционного отображения класса
j
ava

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

В

представлен пример конфигурации класса
E
mployee
. Рассмотрим основные
настройки маппинга:



Аннотация @
Entity

указывает на то, что объект данного класса соо
т-
ветствует сущности базы данных из таблицы
employee



Аннотация @
Id

определяет уникальный идентификатор объекта, да
н-
ное поле отображается в
первичный ключ в таблице базы данных. А
н-
нотация @GeneratedValu
e

говорит о том, что значение первичного
56


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



Аннотация @
ManyToOne

указывает на то, что сущность
Employee

св
я-
зана с сущно
стью
Position

отношением многие к одному. С помощью
аннотации @JoinColumn указывается, какой атрибут таблицы
employee

будет внешним ключом на таблицу
position



Аннотация @
ManyToMany

указывает на то, что сущность
Employee

связана с сущностью
AbscenceReason

о
тношением многие ко многим.
Аннотация @JoinTable говорит о том, что таблица
employee_reason

я
в-
ляется промежуточной между
employee

и
absence
_
reason
.

Свойства класса
Employee

не помеченные аннотациями отображаются
в атрибуты таблицы
employee

соответствующих
типов.


3.2.2

Применение технологии
Spring

data

для вып
олнения запросов в б
а-
зу данных.

Реализация слоя доступа к данным может быть достаточно громоздкой.
Необходимо писать слишком много шаблонного кода,
sql
-
запросов, обрабо
т-
ки ответов от базы данных. Sprin
g Data JPA позволяет значительно упростить
реализацию слоя доступа к данным, сократив усилия, затраченные на него, и
позволяя уделить больше времени тому, что действительно необходимо.
Возможности, предоставляемые фреймворком
Spring Data
[10]
:




Поддержка создания репозиториев, основаных на Spring и JPA



Поддержка

Querydsl
, т.е. типобезопасные JPA запросы



Прозрачный аудит для доменных классов



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



Проверка запроса во время загрузки при указании аннотации

@Query



Поддержка XML
-
конфигурирования для сущностей

57




Поддержка
j
ava
-
конфигурирования репозитория при указании аннот
а-
ции

@EnableJpaRepositories

В р
амках разработки системы учета рабочего времени были реализов
а-
ны репозитории для доступа к таблицам данных. Для каждого класса
-
сущности был создан собственные интерфейс, унаследованный от интерфе
й-
са
JpaRepository
. Он предлагает основные
CRUD

операции:



save

-

сохранение или обновление сущности. Соответствует
sql

опер
а-
торам
insert

и
update



find



поиск сущности в базе данных. Соответствует
sql

оператору
s
e-
lect






удаление сущности из базы данных.

Помимо использования стандартных методов, предоставляемых

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

findAttendancesByEmployeeAndStartAfterAndFinishBeforeOrderByStart
(

Employee employee,



finish

)

В качестве параметров данный метод принимает объект класса
Emplo
y-
ee
, для которого выполняется запрос, а также интервал
времени. Данный м
е-
тод возвращает результат типа

List
Attendance¤t4;&#xt-3e;&#xn4d-;Ψn;&#x-3ce;耀
-

список объектов с инфо
р-
мацией о присутствии сотрудника.




58


3.2.
3

Разработка

R
EST

API.
Контроллеры

Spring Framework.

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

протокола. В общем
случае,
REST

взаимодействие осуществляется посредством стандартных
Http

запросов

или
POST

для обмена данными.

Для разработки веб сервиса на основе архитектуры
REST

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

запросов были созданы с использованием контроллеров
Spring

Framework
.
Каждый запрос, поступающий в систему, перехваты
вается гл
о-
бальным Front
-
контроллером, который по специфическим параметрам URI,
метод, или заголовки запроса) определяет, какому из контроллеров передать
полученный запрос. Контроллер обрабатывает запрос и
возвращает ответ
[10]
.

В рамках
реализации

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

и
его
методов представлено в та
б-
лице 5.


Таблица 5


описание
REST

контроллера

EmployeeRestController

URI
-

адрес

Метод
запроса

Параметры

Описание



active

Возвращает список
сотрудников в сист
е-
ме в зависимости от
их статуса

59


Проолжение таблицы 5.




employeeId


Возвращает данные
сотрудника по его
id
.

/employee/update_absence


POST

addAbsence

reasonId

absenceDate

employeeId


Добавляет или обно
в-
ляет информацию об
отсутствии сотрудн
и-
ка.




employeeId

from

to

Возвращает
журнал
времени для сотру
д-
ника.


3.3

Разработка клиентской части приложени
я
.

Клиентская часть
разработанной

системы является основным инте
р-
фейсом работы с приложением. Она включает в себя веб
-
интерфейс, посре
д-
ством

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

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

Программа
-
клиент, которая будет отправлять на сервер данные, должна
соответствовать следующим требованиям:



Уметь определять моменты вклю
чения/выключения компьютера, а
также блокирования/разблокирования операционной системы.



Иметь возможность отправлять сигналы об этих событиях на сервер.

Основная программа
-
клиент, которая будет обмениваться с сервером
информацией о статусе работы персональ
ного компьютера сотрудника, ре
а-
60


лизована на языке
java

с использованием фреймворка
Spring

Boot
. Для о
т-
правки сообщения на сервер используется
http

протокол. Для отправки з
а-
просов применяется класс
HttpClient

из пакета org.apache.httpcomponents. Он
предостав
ляет доступ к методам для отправки стандартных
http

запросов.
Пример отправки
post

запроса на сервер:

HttpClient

httpClient

=
HttpClientBuilder
.
create
().
build
();

HttpPost post =
new
HttpPost(
SAVE_ATTENDANCE_URI
);

httpClient
.
execute
(
post
);

В первой строке создается объект класса
httpClient
. Далее создается
объект запроса
HttpPost
, в качестве параметра которому передается
url

адрес
на сервере, к которому будет сделан запрос. И далее вызовом метода
execute

запрос выполняется.

Но использование
языка
java

при реализации клиентской программы
накладывает определенные ограничения, а именно невозможность опред
е-
лить события блокирования и разблокирования операционной системы. Чт
о-
бы решить эту проблему, необходимо использовать языки, которые позвол
я-
ют
подписываться на системные события. При реализации данной системы
учета рабочего времени, для того, чтобы реагировать на события операцио
н-
ной системы, была разработана дополнительная программа на
c
#. Она позв
о-
ляет подписываться на системные события
windows

и назначать обработчики
для этих событий
[11]
. Код данной программы приведен в приложении

Г
.

Диаграмма деятельности работы программы
-
клиента приведена на р
и-
сунке

9
.


61



Рисунок 9
-

д
иаграмма деятельности работы программы
-
клиента

После включения компьютера происходит старт двух программ
-
клиентов.
Java
-
клиент отправляет на сервер данные о старте работы сотру
д-
ника за компьютером.
C
#
-
клиент подписывается на системное событие
Sy
s-
temEvents
.
SessionSwitch
[11]
. В результате срабатывания да
нного события на
сервер посылается информация о блокировании, либо разблокировании ко
м-
пьютера. В случае выключения компьютера
java
-
клиент отправляет на сервер
запрос о выключении компьютера и данная информация заносится в базу
данных.




62


3.4

Импорт данных
из внешней системы пункта пропуска.

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

внешней си
стемы, повышенная нагрузка на сервер при выполнении ©т
я-
желыхª операций импорта и обработки данных.

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



Отсутствие у внешней системы универсал
ьного
REST

API
. Информ
а-
ция из системы контроля пропуска доступна только через веб
-
интерфейс. Таким образом полезную информацию можно получить
только в виде
html

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



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

необходимо учитывать это при разработке пр
о-
цедуры импорта.

Для решения проблемы с доступностью данных только
в
html

формате
разработан парсер, который обрабатывает структур
у

html

документа и извл
е-
кает оттуда информацию о времени прибытия и отбытия сотрудника из оф
и-
са.

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

Scheduling
. Это позволяет задать
периодичность выполнения операции импорта и синхронизации данных.

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

10.

63



Рисунок 10


диаграмма последовательности импорта данн
ых системы
контроля пропуска

На первом этапе происходит старт процесса импорта данных из сист
е-
мы контроля пропуска по расписанию. Планировщик задач вызывает сервис
импорта
timeImport
) и сообщает ему, что необходимо инициировать процесс
импорта 1). Далее се
рвис импорта поочередно для каждого сотрудника в
ы-
полняет ряд операций. Сначала посылается запрос на авторизацию во вне
ш-
нюю систему 2). После успешного ответа об авторизации 3) делается след
у-
ющий запрос, непосредственно самих данных. В теле запроса передают
ся п
а-
раметры временного отрезка, для которого необходима информация. В р
е-
зультате от внешней системы приходит
html

документ 4). После этого нео
б-
ходимо получить полезную информацию из
html

документа. Для этого се
р-
вис
timeImporter

вызывает сервис
documentParser

и передает ему исходный
html

код 5).
DocumentParser

обрабатывает
html

документ, получаем из него
64


нужную информацию и записывая ее в соответствующую структуру
java

объектов.
Java

объекты с полученной информацией возвращаются в сервис
timeImpo
rter
6). После этого делается запрос в базу данных, чтобы получить
информацию о присутствии сотрудников за этот же период, которая была
получена самой системой от рабочих компьютеров сотрудников) 7). Далее
происходит обработка информации, полученной из баз
ы данных 8) и инфо
р-
мации, полученной из внешней системы. Происходят процессы синхрониз
а-
ции и разрешения конфликтов 9) в результате которой получается итоговый
набор данных о времени присутствия сотрудников в офисе. Данная инфо
р-
мация заносится в базу данных
.


Вывод.

Разработанная система соответствует требованиям, предъявленным к
ней в главе 2. Она предлагает пользовательский интерфейс, а также автом
а-
тический трекинг времени.

Технологии, использованные при разработке системы и созданные
API
,
позволяют гибко

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









65


Глава
4.

Составление бизнес
-
плана по коммерциализации результатов
НИР магистранта.


Разработка технико
-
экономического обоснования ТЭО) в рамках да
н-
ной выпускно
й квалификационной работы позволяет обосновать экономич
е-
скую целесообразность проведённых работ.

Выполненное ТЭО позволяет оценить затраты связанные с разработкой
системы учета рабочего времени СУРВ ©
WorkTime
ª и определить какой вид
работ оказался самым до
рогостоящим.


4.1

Описание продукта.

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

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

доступа к системе средствами
HTTP

запроса, который дает возможности и
н-
66


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


4.2

Анализ рынка сбыта продукции.

Учет рабочего времени сотрудников в той или иной степени примен
я-
ется на всех предприятиях. При этом,

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

он использует рабочее время.

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

предприятиях, производящих интеллектуальный продукт:
институты,
IT

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

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


4.3

Анализ альтернативны
х систем учета рабочего времени
.

Рынок систем учета рабочего времени очень разнообразен. Выбор по
д-
ходящей системы напрямую зависит от потребностей бизнеса, размера пре
д-
приятия, бюджета, который руководство готово выделить на это.
Крупные
предприятия готовы тратить достаточно большие деньги, покупая решения
enterprise
-
уровня. Такие системы зачастую используют последние технол
о-
67


гии, такие как радиочастотные метки, биометрические данные для контроля
доступа. Часто они идут вместе с дру
гими приложениями в рамках единой
ERP
-
системы.


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


В качестве метрик сравнения выберем те, которые имеют
наибольшую важность при разработке системы учета рабочего времени в
рамках данной ВКР:



Гибкий
график.

Возможность гибкого графика. Например, пришел с 8
до 10:30 ушел с 17 до 20, обед 30
-
40 мин в любое время.



Заявки на отпуск, отгул.

Возможность помечать дни как отпуск, отгул,
деловая поездка



Наличие API


возможность интегрировать систему с другими

корп
о-
ративными приложениями посредство универсальных
API
.



Доступ к статистике.

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


Сравнительный анализ возможностей
выбранных систем продемо
н-
стрирован в таблице 4.3.1.

Таблица 4.3.1.


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

Система

Гибкий
график

Заявки на о
т-
пуск, отгул

Наличие
API

Доступ к
статистике

ManicTime

+/
-

-

+

+

Yaware

+/
-

-

+

+


68


Продолжение таблицы 4.3.1.

Crocotime

+

-

+

+

TimeCamp

+

-

+

+

СУРВ
©
WorkTime
ª

+

+

+

+



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


4.4

Определение трудоемкости работ.

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

Под проектирова
нием будем понимать совокупность работ, которые
необходимо выполнить, чтобы решить поставленную в ВКР задачу.

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





͵

୫ ୬

2


ͷ







(1)

69


где



-

ожидаемая длительность j
-
й работы; t
min

и t
max

-

наименьшая и
наибольшая, по мнению эксперта, длительность работы. Продолжительность
работ ед.t) можно измерять в человеко
-
часах или человеко
-
днях.

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

Таблица
4
.4.1.
-

Длительность этапов разработки.



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

Длительность работы,

дней

t
min

t
max

t
0

1

Изучение литературы и информацио
н-
ных ресурсов по предметной области

10

15

12

2

Анализ существующих решений

5

10

7

3

Выбор инструментов реализации

3

5

3,8

4

Проектирование системы

15

20

17

5

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

25

40

31

6

Тестирование системы

15

20

17

7

Оформление пояснительной записки

10

14

11,6

Итого

83

124

99,4


4.5

Расчет заработной платы и отчислений на социальные нужды.

Расходы на основную заработную плату определяются по формуле 2):


осн


пл


















(2)

где
З
осн.з/пл



расходы на основную заработную плату исполнителей;
k



количество исполнителей;
T
i



время, затраченное
i
-
м исполнителем на да
н-
ном этапе;
C
i



ставка заработной платы
i
-
го исполнителя.

70


Определим ставки заработной платы руководит
еля и студента за один
рабочий день. Для этого необходимо заработную плату за месяц разделить на
21 день. В качестве ставки заработной платы руководителя возьме зарплату
специалиста уровня старшего инженера
-
программиста. Она составляет
100000 руб. Ставка с
тудента будет равна зарплате программиста среднего
уровня 70000 руб.

Дневная заработная плата руководителя:


рук

૚૙૙૙૙૙

ру
૛૚

н

૝ૠ૟૛

ру

н

Дневная заработная плата студента:


сту

ૠ૙૙૙૙

ру
૛૚

н

૜૜૜૜



ру

н

Расчеты основной заработной

платы сведены в таблицу 4.5.1.

Таблица 4.5.1.
-

Расходы на основную заработную плату.



Этапы и содержание выпо
л-
няемых работ

Трудоемк.,
t
0

дней

З
осн.з/пл
,
руб.

Руководитель

Студент

1

Изучение литературы и и
н-
формационных
ресурсов по
предметной области

0

12

3999
9,6

2

Анализ существующих реш
е-
ний

0

7

2333
3,1

3

Выбор инструментов реал
и-
зации

0,8

3

1380
1
,
5

4

Проектирование системы

0

17

5666
6,1

5

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

0

31

1033
32,3

6

Тестирование системы

10

7

7095
3,1

7

Оформление пояснительной
записки

2

9,6

4152
3
,
7

Итого

12,8

86,6

349
617
,4


71


Основная заработная плата руководителя:


осн


пл

૚૛



н й

૝ૠ૟૛
ру
н

૟૙ૢ૞૜



ру

Основная заработная плата студента:


осн


пл

ૡ૟



н й

૜૜૜૜


ру
н

૛ૡૡ૟૟૜



ру

Общая сумма расходов на основную заработную плату: 349617,4 руб.

Расходы на дополнительную заработную плату определим по формуле
(3):


оп


пл



осн


пл


оп
૚૙૙







(3)

где З
доп.з/пл



размер дополнительной заработной пл
аты, З
осн.з/пл



размер
основной заработной платы, Н
доп



норматив дополнительной заработной
платы, равный 14%.

Дополнительная заработная плата руководителя:


оп


пл

૟૙ૢ૞૜



ру

૚૝
૚૙૙

ૡ૞૜૜



ру

Дополнительная заработная плата студента:



оп


пл

૛ૡૡ૟૟૜



ру

૚૝
૚૙૙

૝૙૝૚૛



ру

Общая сумма расходов на дополнительную заработную плату: 48946,4
руб.

Отчисления на страховые взносы на обязательное социальное, пенс
и-
онное и медицинское страхование с основной и дополнительной
заработной
платы исполнителей определим по формуле 4):


со


(

оп


пл


осн


пл
)


со
૚૙૙






(4)

где З
соц



отчисления на социальные нужды с заработной платы руб.),
З
доп.з/пл



размер дополнительной заработной платы исполнителя, З
осн.з/пл



разме
р основной заработной платы исполнителя, Н
соц



норматив отчислений
72


на страховые взносы на обязательное социальное, пенсионное и медицинское
страхование равный 30%.

Отчисления на социальные нужды с заработной платы руководителя:


со

(
ૡ૞૜૜




ру




ૢ૞૜



ру
)

૜૙
૚૙૙

૛૙ૡ૝૟



ру

Отчисления на социальные нужды с заработной платы студента:


со

(
૝૙૝૚૛



ру


૛ૡૡ૟૟૜



ру
)

૜૙

-


ૢૡૠ૛૜

ру

Общая сумма отчислений на социальные нужды: 119569,1 руб.


4.6

Расчет затрат на
материалы и услуги сторонних организаций.

Поскольку данная ВКР бакалавра не предполагает изготовление сте
н-
дов, приборов или опытных образцов, то затраты на их изготовление не
определяются. При этом потребуется оценка затрат на материалы и услуги,
оказанные

сторонними организациями.

Себестоимость по каждой из статей можно рассчитать нормативным
методом. Для этого необходимо знать параметры продукции нормы расх
о-
да), заложенные в конструкторско
-
технологической документации. Расчеты
производятся по формуле
(5).









(



т


૚૙૙
)












(5)

где





затраты на сырье и материалы руб.);
l



индекс вида сырья
или материала;





норма расхода l
-
того материала на единицу продукции
ед.);





цена приобретения единицы l
-
го материала руб./ед.);

т





норма
транспортно
-
заготовительных расходов %).

При выполнении расчетов в ВКР норму транспортно
-
заготовительных

расходов

т


) принимаем равной 10%.


В ходе выполнения данной выпускной квали
фикационной работы
была приобретена услуга по распечатке пояснительной записки. Общий об
ъ-
73


ем пояснительной записки составляет 89 страниц при стоимости распечатки
одной страницы 5 руб. Также была приобретена папка для ВКР магистра
стоимостью 200 рублей.


Так

как основным инструментом выполнения ВКР является пе
р-
сональный компьютер, необходимо учесть затраты за услугу проставления
электричества. Согласно сайту energo
-
24.ru, одноставочный тариф для нас
е-
ления с 1 января 2017 года равен 4,12 руб. за кВт*ч, включая

НДС. В соо
т-
ветствии с документацией ноутбука, его энергопотребление составляет 32
Вт*ч
. Время использования ноутбука студентом равно 692,8 ч.

Расчеты затрат на сырье представлены в таблице 4.6.1.


Таблица
4
.6.1.
-

Затраты на сырье.

Материал или
услуга

Нор
ма ра
с-
хода, ед.

Цена за
единицу,

руб.

Сумма,

руб.

Печать поясн
и-
тельной записки

89

5

445

Папка для ВКР

1

200

200

Расходы на
электроэнергию

22,2 кВт*ч

4,12

91,5

ИТОГО

736,5


4.7

Определение величины амортизационных отчислений использу
е-
мых основных
средств.

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



74


Амортизационные отчисления по основному сред
ству i за год опред
е-
ляются по формуле 6):





п

н





૚૙૙







(6)

где





амортизационные отчисления за год по i
-
му основному сре
д-
ству руб.);

п

н





первоначальная стоимость i
-
го основного средства руб.);





годовая норма амортизации i
-
го основного средства %).

Для определения величины амортизационных отчислений по основным
средствам, используемым в процессе выполнения ВКР необходимо опред
е-
л
ить время, в течение которого студент использует это основное средство. В
данном случае это
692,8

часа из расчёта времени, потраченного студентом

Годовая норма амортизации для вычислительной техники рассчитыв
а-
ется исходя из его срока полезного использовани
я. Для ноутбука этот срок
составляет 3 года. Получим 100% / 3 33,3%.

Далее, определяем, какую часть от года составляет период, в течение
которого студент использовал основное средство.

Примем, что в одном месяце 21 рабочий день. При 8
-
часовой смене это
1
68 часов. В году 168*12 2016 часов. Тогда получим, что средство испол
ь-
зовалось:
692,8
/ 2016 0,344 года.

Величина амортизационных отчислений по i
-
му основному средству,
используемому студентом при работе над ВКР, определяется по формуле 7):











૚૛








(7)

где






амортизационные отчисления по i
-
му основному средству,
используемому студентом в работе над ВКР руб.);





амортизационные
отчисления за год по i
-
му основному средству руб.);






время, в течение

ко
торого студент использует i
-
ое основное средство мес.). Для удо
б-
ства, сведём расчёты в таблицу 5.7.1.



75


Таблица 4.7.1.
-

Амортизационные отчисления по основному средству.

Наимен
о-
вание

Первон
а-
чальная сто
и-
мость, руб

Амортизац.
отчисления за год,
руб

Аморт
и-
зац. отчисления
за ВКР
, руб.

Ноутбук

34800.00

11600

3990,4

ИТОГО

34800.00

11600

3990,4


4
.8

Определение накладных расходов.

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

выполняется ВКР. В данном случае процент накладных расходов равен 40.


Накладные расходы считаются по формуле 8):


нр

(



пл


со
)


нр
ͳ--








(8)

где

нр


величина накладных расходов,



пл



расходы на оплату тр
у-
да,

со



отчисления на социальные нужды,

нр



процент накладных расх
о-
дов.


нр

(
͵49ͷ9ͳ

4

ру

ͳͳ9ͷ͸-

ру
)

4-
ͳ--

ͳͺ͹͸͸-

͸

ру




4.9

Определение совокупной величины затрат, связанных с разрабо
т-
кой
системы.

Для расчета совокупной величины затрат, связанных с выполнением
ВКР, сведём все проведенные расчеты и оформим в таблице 5.9.1.

Таблица 4.9.1.
-

Смета затрат на ВКР.


к/п

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

Сумма,
руб

1

Расходы на оплату труда

398581.8

76


Продолжение таблицы 4.9.1


4
.10

Рентабельность.

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


Если предположить, что предприятие, на котором будет внедрена
эта система состоит из 20 человек и заработная плата каждого из них соста
в-
ляет 48
000 руб. средняя зарплата по Санкт
-
Петербургу). При этом каждый из
сотрудников не дорабатывает в среднем 30 минут в день, то внедрение да
н-
ной системы позволит сэкономить 60000 руб. в месяц. При себестоимости
разработки 710537 руб. она окупит себя в течение

года.


Вывод:

В
данной глав
е

выпускной квалификационной работы было
рассчитано

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

Отчисления на социальные нужды

119569,1

3

Материалы и сырье

736,5

4

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

3990,4

5

Накладные расходы

187660

ИТОГО

710537.8

77


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


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
























78


Заключение


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

Разработанная система решает задачи, поставленные перед ней, и у
д
о-
влетворяет требуемому функционалу.

Она учитывает данные, которые авт
о-
матически отправляют ей персональные компьютеры сотрудников

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

контроля пропуска.

Помимо
реализованного

функционала, система

учета рабочего времени
и
меет точки расширения и интеграции

с другими внешними системами
.

Это
обеспечивается выбранными технологиями


в первую очередь тем, что се
р-
вер системы реализован в виде веб
-
приложения, что позволяет создать и
расширить универсальный
REST

API

для обмена данными по
http

протоколу.
Также, выбранный стек технологий на основе
Spring

Framework

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

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




79


Список использованных источников


1.

Иванов Д. Как вне
дрить систему учёта рабочего времени и не потерять
сотрудников // HR
-
Journal: интернет
-
журнал. [Электронный ресурс].
URL: http://www.hr
-
journal.ru/articles/oc/vnedrenie
-
sistemy
-
uchyota
-
rabochego
-
vremeni.html дата обращения 30.04.17)

2.

Орлова Е.В. Системы
учета рабочего времени // Справочник кадровика
:
интернет журнал. [Электронный ресурс]. URL: https://www.pro
-
personal.ru/article/131213
-
rabochee
-
vremya
-
kak
-
postroit
-
sistemu
-
дата обращения 2.0
5
.17)

3.

RFID Tags

-

Radio Frequency Identification Tags.
[Эл
ектронный ресурс].
URL: http://www.rfident.org/ дата обращения 5.0
5
.17)

4.

Дубенецкий В.А., Советов Б.Я., Цехановский В.В. Проектирование
корпоративных информационных систем.
СПб: издательство

СПбГЭТУ ©ЛЭТИ
ª
, 2013
.

191 с.

5.

Архитектура информационных систем /
Советов Б.Я., Водяхо А.И., Д
у-
бенецкий В.А. Цехановский В.В.

М.: Издатель
ский центр ©Академияª,
2012.
288 с.

6.

Л. Басс, П. Клементс, Р. Кацман.
Архитектура программного обеспеч
е-
ния на практике
. СПб
:
Питер,
2006.
576 с.

7.

Филдинг

Р
. Representational State Transfer (REST).
[Электронный р
е-
сурс].
URL:
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
l

дата обращения 10.05.17)

8.

Автоматизация работы с Gulp //
WebReference.ru
: информ
ационный
портал для веб
-
разработчиков. [Электронный ресурс]. URL:
https://webref.ru/dev/automate
-
with
-
gulp

дата обращения 1
1
.0
5
.17)

9.

Spring Boot


быстрый старт // Сайт с документацией Spring Framewotk.
[Электронный ресурс]. Url:
http://spring
-
projects.ru/projects/spring
-
boot/
дата обращения 13.05.17)

80


10.

Уоллс К. Spring в действии. М: ДМК Пресс, 2015. 752 с.

11.

Шилдт Г. C# 4.0. Полное руководство. М: ООО ©И.Д. Вильямсª, 2013.
1056 с.


























81


Приложение

А
.

Pom
-
файл
проекта
-
сервера.


?
xml

version
="1.0"
encoding
="
UTF
-
8"
�?


project

xmlns
="
http
://
maven
.
apache
.
org
/
POM
/4
.0.0"


xmlns:xsi="http://www.w3.org/2001/XMLSchema
-
instance"


xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven
-
4.0.0.xsd"




modelVersion

4.0.0
/
modelVersion





groupId

spiiras
/
groupId




artifactId

worktime.server
/
artifactId




version

1.0
-
SNAPSHOT
/
version





parent




groupId

org.springframework.boot
/
groupId




artifactId

spring
-
boot
-
starter
-
parent
/
artifactId




version

1.5.2.RELEASE
/
version



/
parent





properties




java.version

1.8
/
java.version



/
properties





dependencies




dependency




g
roupId

org.postgresql
/
groupId




artifactId

postgresql
/
artifactId




version

9.3
-
1100
-
jdbc4
/
version



/
dependency




dependency




groupId

org.springframework.boot
/
groupId




artifactId





spring
-
boot
-
starter
-
data
-
jpa



/
artifactId



/
dependency




dependency




groupId

org.springframework.boot
/
groupId




artifactId

spring
-
boot
-
starter
-
web
/
artifactId



/
dependency




dependency




groupId

org.springframework.boot
/
groupId




artifactId





spring
-
boot
-
starter
-
thymeleaf



/
artifactId



/
dependency




!
--

Apache HttpClient
--




dependency




groupId

org.apache.httpcomponents

/
groupId




artifactId

httpclient
/
artifactId




version

4.5.2
/
version


82



/
dependency





dependency




groupId

org.hibernate
/
groupId




artifactId

hibernate
-
java8
/
artifactId




version

5.2.5.Final
/
version



/
dependency





dependency




groupId

com.google.code.gson
/
groupId




artifactId

gson
/
artifactId




version

2.8.0
/
version



/
dependency



/
dependencies





bui
ld




finalName

WTServer_1.0
/
finalName




resources




resource




directory

src/main/resources
/
directory




excludes




exclude

**/*.scss
/
exclude



/
excludes



/
resource



/
resources




plugins




plugin




groupId

org.springframework.boot
/
groupId




artifactId





spring
-
boot
-
maven
-
plugin




/
artifactId



/
plugin




plugin




groupId

/
groupId




artifactId

frontend
-
maven
-
plugin
/
artifactId




version

1.0
/
version




executions




execution




id

in
stall node and npm
/
id




goals




goal

install
-
node
-
and
-
npm
/
goal



/
goals




configuration




nodeVersion

v4.5.0
/
nodeVersion




npmVersion

3.9.5
/
npmVersion



/
configuration



/
execution




execution




id

npm install
/
id




goals





goal

npm
/
goal



/
goals


83



/
execution




execution




id

gulp build
/
id




goals




goal

gulp
/
goal



/
goals



/
execution



/
executions



/
plugin



/
plugins



/
build


/
project

























84


Приложение Б. Файл сборки
gulpfile
.
js


var
gulp = require(
'gulp'
),


rename = require(
'gulp
-
rename'
),


concat = require(
'gulp
-
concat'
),


sass = require(
'gulp
-
sass'
),


babel = require(
'gulp
-
babel'
);


const
SRC_ROOT_DIRECTORY =
'./src/main/resources'
;


gulp.task(
'default'
, [
'js'
],
function
() {


gulp.src
([SRC_ROOT_DIRECTORY +
'/**/*.scss'
])


.pipe(concat(
'index.scss'
))


.pipe(sass().on(
'error'
, sass.logError))


.pipe(gulp.dest(
));

});


gulp.task(
'js'
,
function
() {


gulp.src([SRC_ROOT_DI
RECTORY +
'/**/*.js'
,

SRC_ROOT_DIRECTORY +
'/**/*.jsx'
])


.pipe(babel({


'es2015'
,
'react'
]


}))


.pipe(concat(
'index.js'
))


.pipe(gulp.dest(
));

})

























85


Приложение В.
JPA

конфигурация класса
Employee


@Entity

public class
Employee {



@Id


@GeneratedValue(strategy= GenerationType.
IDENTITY
)


private
Long
id
;


private
String
name
;


@ManyToOne


@JoinColumn(name =
"position_id"
)


private
P
osition
position
;


private
String
signatureUri
;


private boolean active
;


private
String
ip
;


ALL
)


@JoinTable(name =
"employee_reason"
, joinColumns =
@JoinColumn(name =
"employee_id"
, referencedColumnName
=
"id"
),


inverseJoinColumns = @JoinColumn(name =
"reason_id"
,
referencedColumnName =
"id"
))


private
employeeReasons
;



public
Employee() {


}



public
Employee(String name, Position position, String si
g-
natureUri,

boolean
y-
eeReasons) {


this
.
name
= name;


this
.
position
= position;


this
.
signatureUri
= signatureUri;


this
.
active
= active;


this
.
ip
= ip;


this
.
employeeReasons
=
employeeReasons;


}

}
















86


Приложение Г. Программа
-
клиент на языке
C
#


using System;

using System.Collections.Generic;

using System.Text;

using System.Runtime.InteropServices;

using System.Diagnostics;


namespace hide

{


class Program


{


[DllImport("kernel32.dll")]





[DllImport("user32.dll")]


static extern bool ShowWindow(IntPtr hWnd, int
nCmdShow);



const int SW_HIDE = 0;


const int SW_SHOW = 5;




static void Main(string[] args)


{





ShowWindow(handle, SW_HIDE);


SystemEvents.SessionSwitch += SESS;


Console.Read();


}



static

void SESS(object sender, SessionSwitchEventArgs
e)


{


//Console.WriteLine("Evenst SessionSwitch = "+
e.Reason);


if (e.Reason.ToString() == "SessionLock")


{


lockSystem();


}


else


{


unlockSystem();


}


}



static void lockSystem()


{


WebRequest request = WebR
e-
quest.Create("http://localhost:8089/system/lock ");



87




request.ContentType = "application/x
-
www
-
form
-
urlencoded";






reader.Close();


dataStream.Close();


response.Close();


}



static void unlockSystem()


{


WebRequest request = WebR
e-
quest.Create("http://localhost:8089/system/unlock ");




request.ContentType

= "application/x
-
www
-
form
-
urlencoded";






reader.Close();


dataStream.Close();


response.Close();



}


}

}


Приложенные файлы

  • pdf 7715156
    Размер файла: 2 MB Загрузок: 0

Добавить комментарий