Моделирование предметной области “Кадровое делопроизводство” с помощью UML

Содержание:

Введение

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

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

Объектом исследования является технология кадрового делопроизводства.

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

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

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

Задачи работы:

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

- анализ мероприятий по совершенствованию технологии кадрового делопроизводства;

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

- постановка задач автоматизации.

1.Аналитическая часть

1.1. Описание предметной области. Постановка задачи

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

К стандартным задачам кадрового учета относятся:

- кадровые перемещения;

- прием/увольнение сотрудников;

- учет командировок;

- печать табелей учета рабочего времени;

- печать справок о стаже, о месте работы;

- подготовка стандартной отчетности.

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

Типовыми задачами технологии кадрового учёта являются:

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

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

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

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

- учет особенностей ведения специального стажа;

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

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

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

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

1.2. Предлагаемые мероприятия по улучшению бизнес-процессов

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

- учет кадровых данных сотрудников;

- ведение учета времени нахождения сотрудников в командировке;

- учет отпусков;

- учет листов нетрудоспособности;

- формирование табеля учета рабочего времени;

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

Приведем анализ экономической сущности задач учета рабочего времени сотрудников. Всего задачи технолога можно разделить на три группы:

- Помощь специалистам по кадрам в поиске информации о сотрудниках;

- Помощь в поиске информации о нахождении сотрудников в командировках, отпусках, отработанном времени;

- Формирование табеля учета рабочего времени.

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

Таблица 1 - Частота формирования отчетных документов

№	Название документа	Время формирования без применения автоматизации	Время формирования с применением автоматизации	Частота формирования, раз в год
1	Учет кадровых данных сотрудников	15 мин.	0,5 мин	6000
2	Ввод данных о командировках	15 мин.	0,5 мин.	4000
3	Ввод данных о листах нетрудоспособности	15 мин.	0,5 мин.	4000
4	Учет отпусков	15 мин.	0,5 мин.	6000
5	Формирование табеля учета рабочего времени	15 мин.	1 мин.	7000
6	Формирование аналитического отчета о нагрузке на специалистов	15 мин.	1 мин.	6000
7	Учет невыходов	2 ч.	1 мин.	12
8	Учет сверхурочных	1 ч.	1 мин.	100

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

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

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

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

- наличием субъективности и человеческого фактора при проведении отбора персонала;

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

Основы для расчёта по предметной области: по статистике и прогнозу, для комплектации штата VENGO GROUP, в среднем за год, - требуется 40 новых сотрудников.

Подбором персонала занимаются 2 (Два) HR-специалиста:

поиск по БД резюме по параметрам вакансии						переговоры		встречи / анкеты		кадровое делопроизводство
0%	10%	20%	30%	40%	50%	60%	70%	80%	90%	100%	переработка

Добавляем к работе HR-специалистов услуги от робота «ВЕРЫ»:

Тогда занятость HR-специалистов в поиске и подборе персонала, можно представить так:

поиск по БД		переговоры	встречи / анкеты					кадровое делопроизводство
0%	10%	20%	30%	40%	50%	60%	70%	80%	90%	100%	переработка

Стоимость услуг робота «ВЕРА» составляется продавцом из расчёта на 1 год для поиска и отбора 40 новых сотрудников:

- необходимо совершить 50 звонков (как минимум) чтобы получить 1 отклик для формирования группы отбора на 1 вакансию;

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

- для подбора 1 сотрудника, нужно совершить 2 500 звонков,

- для 40 новых сотрудников (план на год) 100 000 звонков с целью набора 2 000 потенциальных кандидатов;

- 100 000 звонков будут стоить для VENGO GROUP примерно 350 0000 руб.

В эту цену входит аналитика, формирование тайминга по встречам кандидатов с HR-специалистами для анкетирования и тестирования.

Представим процесс трудозатрат (по времени и финансам) «AS-IS»

(«ДО» внедрения в работу HR-специалистов услуг от робота «ВЕРА»:

№	Наименование процесса:	в % ресурс: время исполнения		Стоимость процесса
01	Поступила заявка на подбор: (уточнить параметры поиска)	03%		115,20 руб.
		03%	97%
02	Поиск резюме по внутренней БД:	06%		230,40 руб.
		09%	91%
03	Поиск резюме по внешним БД:	41%		1574,40 руб.
		50%	50%
04	Предварительные звонки-собеседования:	20%		768,00 руб.
		70%	30%
05	Встречи, анкетирования, тестирования:	20%		768,00 руб.
		90%	10%
06	Кадровое делопроизводство:	10%		384,00 руб.
		100%	0%
ИТОГО на 1 HR:		100%		3840,00 руб.

Если ввести в процесс возможности робота «ВЕРЫ», то затраты ресурсов каждого HR-специалиста существенно сократятся, а именно:

№	Наименование процесса:	в % ресурс: время исполнения		Стоимость процесса
01	Поступила заявка на подбор: (уточнить параметры поиска для робота)	03%		115,20 руб.
		03%	97%
02	Поиск резюме по всем БД:	00%		00,00 руб.
		00%	97%
03	Контроль результатов поиска:	6%		230,40 руб.
		09%	91%
04	Предварительные звонки-собеседования:	00%		00,00 руб.
		00%	91%
05	Встречи, анкетирования, тестирования:	41%		1574,40 руб.
		50%	50%
06	Кадровое делопроизводство:	50%		384,00 руб.
		50%	0%
ИТОГО на 1 HR:		100%		2303,60 руб.

2. Проектная часть

2.1. Выбор средства для моделирования предметной области решаемой задачи

Методология UML (сокр. от англ. Unified Modeling Language - унифицированный язык моделирования) представляет собой язык графического описания, позволяющий создавать модели. Целью создания UML явилась автоматизация разработки программных продуктов. Главная его цель методологии состояла в достижении единой позиции разработчиков и пользователей в отношении создаваемого ПО.

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

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

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

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

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

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

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

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

Свойство однозначности создаваемых моделей позволяет с использованием специального программного обеспечения (например Rational Rose или Rational XDE) проводить автоматическую генерацию программного кода.

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

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

Проведем характеристику существующих типов диаграмм UML.

1. Диаграммы вариантов использования (Use Case)

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

- определение общих границ и контекста моделируемой прикладной задачи;

- формулировка общих требований к функциональности проектируемой системы;

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

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

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

1. Диаграммы взаимодействия

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

Указанный тип диаграмм отражает следующие стороны проектируемых систем:

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

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

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

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

Для описания взаимодействия объектов в UML предусмотрены следующие виды диаграмм:

Диаграмма последовательности – моделирует последовательность обмена сообщениями между объектами

Диаграмма коммуникаций – модулирует структуру взаимодействующих компонентов (для данного вида диаграммы в UML 1 используется наименование «диаграмма коопераций»)

Временные диаграммы – моделирует изменение состояния нескольких объектов в момент взаимодействия

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

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

1. Диаграммы классов

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

Классы являются основным строительным блоком информационных систем. Данный термин присутствует и в ОО языках программирования, то есть между классами UML и программными классами имеется соответствие, представляющее основу для автоматической генерации программных кодов или для модернизации бизнес-процессов. У каждого класса имеется наименование, атрибуты и операции. Классы на диаграмме представляются в виде прямоугольника, который разделяется на 3 области. В верхней области записывается наименование класса, в средней части – список атрибутов (свойств), в нижней части - наименование операций – услуг, которые предоставляются объектами данного класса.

1. Диаграммы состояний

Диаграммы состояний - это один из видов диаграмм в языке UML, используемых при моделировании динамических аспектов системы (в их число входят также диаграммы последовательностей и кооперации, диаграммы деятельности и диаграммы прецедентов). Диаграммы состояний показывают автомат. Ее частной разновидностью является диаграмма деятельности, в которой все или большая часть состояний - это состояния деятельности, а все или большая часть переходов инициируются в результате завершения деятельности в исходном состоянии. Таким образом, при моделировании жизненного цикла объекта полезны как диаграммы деятельности, так и диаграммы состояний. Но если диаграмма деятельности показывает поток управления от деятельности к деятельности, то на диаграмме состояний представлен поток управления от состояния к состоянию.

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

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

1. Диаграммы деятельностей

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

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

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

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

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

1. Диаграмма компонентов

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

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

Визуализации общей структуры исходного кода программной системы.

Спецификации исполнимого варианта программной системы.

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

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

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

1. Диаграммы размещения

Диаграмма размещения (развертывания) — вторая из двух разновидностей диаграмм реализации UML, моделирующих физические аспекты объектно-ориентированных систем. Диаграмма размещения показывает конфигурацию обрабатывающих узлов в период работы системы, а также компоненты, «живущие» в них.

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

Рассмотрим основные этапы проектирования ИС с использованием UML.

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

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

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

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

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

Диаграммы прецедентов (диаграммы вариантов использования, use case diagrams) представляют собой обобщенную модель функционирования системы в прикладной среде.

Диаграммы видов деятельности (диаграммы деятельностей, activity diagrams) – модель бизнес-процесса или поведения системы в рамках прецедента.

Диаграммы взаимодействия (interaction diagrams) – модель процесса обмена сообщениями между объектами, представляется в виде диаграмм последовательностей (sequence diagrams) или кооперативных диаграмм (collaboration diagrams).

Диаграммы состояний (statechart diagrams) – модель динамического поведения системы и ее компонентов при переходе из одного состояния в другое.

Диаграммы классов (class diagrams) – логическая модель базовой структуры системы, отражает статическую структуру системы и связи между ее элементами.

Диаграммы базы данных (database diagrams) — модель структуры базы данных, отображает таблицы, столбцы, ограничения и т.п.

Диаграммы компонентов (component diagrams) – модель иерархии подсистем, отражает физическое размещение баз данных, приложений и интерфейсов ИС.

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

2.2 Моделирование предметной области решаемой задачи с использованием объектно-ориентированного подхода к проектированию

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

Функциональные требования к системе:

- загрузка резюме;

- учет штатного расписания;

- учет вакансий;

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

- обработка резюме кандидатов по выбранным критериям;

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

Среда реализации: php, СУБД - MySQL.

На клиенте - работа с использованием браузера в независимости от установленной операционной системы.

Наличие системы разграничения доступа:

- для администраторов: доступ к режиму разграничения доступа и справочной информации;

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

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

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

На рисунке 1 приведена Use-Case диаграмма для процесса подбора персонала.

Рисунок 1 – Диаграмма вариантов использования

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

На рисунке 3 показана диаграмма учета отработанного времени сотрудников.

Рисунок 2 – Use-Case диаграмма подсистемы учета кадровых приказов

Рисунок 3 - Use-Case диаграмма подсистемы учета отработанного времени

Диаграмма деятельности приведена на рисунке 4.

Рисунок 4 – Диаграмма деятельности подбора персонала

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

Рисунок 5 – Диаграмма деятельности подсистемы учета рабочего времени

Диаграмма кооперации показана на рисунке 7.

Рисунок 6 - Диаграмма кооперации

Рисунок 7 - Диаграмма компонентов

Заключение

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

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

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

Подводя итог анализа проекта, можно сказать, что поставленная цель оптимизации работы специалистов по работе с персоналом ОАО «Интелком» достигнута.

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

1. Федеральный закон от 28.12.2013 № 426-ФЗ. О специальной оценке условий труда.
2. Трудовой кодекс РФ - Статья 68. Оформление приема на работу.
3. Письмо Минфина России от 11.03.2016 № 03-11-06/2/13564 - УСН: агентство по подбору персонала.
4. Федеральный закон от 05.05.2014 № 116-ФЗ - О внесении изменений в отдельные законодательные акты Российской Федерации … развития негосударственных организаций, осуществляющих деятельность по содействию в трудоустройстве граждан и (или) подбору работников, включая частные агентства занятости, а также для взаимодействия и сотрудничества таких…
5. Егоршин, А.П. Управление персоналом/А.П. Егоршин - Н. Новгород: НИМБ, 2010. - 214 с.
6. Золотые страницы: лучшие примеры внедрения сбалансированной системы показателей:(C. статей) / Сост. М. Горский, А. Гершун / Пер. с англ. М. Павловой. – М.: ЗАО «Олимп – Бизнес», 2008. – 416 с.: ил.
7. Иванцевич, Дж. М., Лобанов, А.А. Человеческие ресурсы управления. Основы управления персоналом / А.А. Лобанов. - М.: Дело, 2010. - 378 с.
8. Иванцевич, Дж. М., Лобанов, А.А. Человеческие ресурсы управления. Основы управления персоналом / А.А. Лобанов. - М.: Дело, 2010. - 378 с.
9. Кибанов А.Я., Ивановская Л.В. Управление персоналом: теория и практика. Кадровая политика и стратегия управления персоналом: учебно-практическое пособие/под ред. А.Я. Кибанова. - М.: Проспект, 2012. – 240 с.
10. Клочков А. К. KPI и мотивация персонала. Полный сборник практических инструментов. — ЭКСМО, 2010. — 160 с.
11. Кондраков, Н.П. Основы малого и среднего предпринимательства: Практическое пособие / Н.П. Кондраков, И.Н. Кондраков. М.: НИЦ ИНФРА-М, 2013. - 446 c.
12. Круглова, Н.Ю. Основы бизнеса (предпринимательства): Учебник / Н.Ю. Круглова. - М.: КноРус, 2013. - 440 c.
13. Круглова, Н.Ю. Основы бизнеса (предпринимательства): Учебник / Н.Ю. Круглова. - М.: КноРус, 2013. - 440 c.
14. Макаров, С.И. Основы предпринимательства / С.И. Макаров, М.В. Мищенко. - М.: КноРус, 2013. - 224 c.
15. Макаров, С.И. Основы предпринимательства / С.И. Макаров, М.В. Мищенко. - М.: КноРус, 2013. - 224 c.
16. Маслов В.И. Стратегическое управление персоналом в условиях эффективной организационной культуры: Учебник. М.: «ФИНПРЕСС», 2004.
17. Митрофанова Е.А., Коновалова В.Г., Белова О.Л. Управление персоналом: теория и практика. Компетентностный подход в управлении персоналом: учебно-практ.-ое пособие/под ред. А.Я. Кибанова. - М: Проспект, 2012.
18. Мишурова, И.В., Кутелов, П.В. Управление мотивацией персонала: Учебно-практическое пособие/ И.В. Мишурова. - Москва: ИКЦ "МарТ"; Ростов н/Д: Издательский центр "МарТ", 2011. - 224 с.
19. Разработка сбалансированной системы показателей. Практическое руководство с примерами. – 2 изд. расшир. / Под ред. А.М. Гершуна, Ю.С. Нефедьевой. – М.: ЗАО «Олимп – Бизнес», 2005, 128 с.
20. Сергеев, А.П. Основы бизнеса (предпринимательства) (для бакалавров) / А.П. Сергеев. - М.: КноРус, 2013. - 440 c.
21. Сергеев, А.П. Основы бизнеса (предпринимательства) (для бакалавров) / А.П. Сергеев. - М.: КноРус, 2013. - 440 c.
22. Сорокина А.В. Механизм реализации эффективной стратегии компании с помощью сбалансированной системы показателей. Учебное пособие для студентов магистратуры по направлению «Менеджмент». МИИТ, 2011, 153 с.
23. Яхонтова Е.С. Стратегическое управление персоналом: Учебное пособие. - М.: РАНХиГС, «Дело», 2013. – 231 с.