Файл: .Разработка проекта информационной системы подбора, найма и сопровождения трудовых ресурсов.pdf

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

Рисунок 7. Контекстная диаграмма бизнес-процесса

Рисунок 8. Декомпозиция контекстной диаграммы

Рисунок 9. Модель процесса формирования персонала

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

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

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

---

Рисунок 10. Модель процесса использования персонала

Рисунок 11. Модель процесса аудита персонала

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

Различают два типа требований к информационной системе [8]:

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

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

1. Специалист по кадрам.
2. Администратор.

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

1. Создание карточек сотрудников.
2. Создание кадрового резерва.
3. Создание графика отпусков.
4. Создание штатного расписания.
5. Учет рабочего времени, формирование табеля.
6. Формирование платежных ведомостей.
7. Выявление потребности в кадрах.
8. Формирование отчетов.
9. Формирование документов.

Требования администратора:

1. Создание пользователя.
2. Удаление пользователя.
3. Создание, изменение и удаление пароля пользователя.
4. Создание группы пользователей.
5. Удаление группы пользователей.
6. Редактирование группы пользователей.
7. Редактирование прав доступа.
8. Формирование отчетов.
9. Удаление карточек работников.
10. Удаление документов.

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

• 1. Первая категория (runtime) содержит атрибуты, которые имеют значение во время работы с ИС.
  2. Вторая категория (designtime) определяет атрибуты, относящиеся к аспектам проектирования приложения.

Рассмотрим нефункциональные требования первой категории [9]:

• 1. Доступность информационной системы: система должна обеспечивать работу в рабочее время организации (с понедельника по пятницу с 09:00 по 18:00).
  2. Надежность – при сбое и ошибках в работе приложения ИС должна сохранить введенные данные и осуществить перезапуск приложения. Время восстановления работоспособности системы при любых сбоях и отказах не должно превышать одного часа рабочего времени, исключая случаи неисправности серверного оборудования.
  3. Требования к долговременному хранению результатов работы приложения – в приложении используется база данных, которая хранится на сервере учреждения. Данные в базе данных подлежат неограниченному хранению. Ежедневно в 20:00 система должна осуществлять резервное копирование данных. Резервные копии хранятся в течении трех месяцев.
  4. Требования к масштабированию – у ИС должна быть возможность переноса приложений на более мощные системы и поддержка большого объема памяти, а также использование технологий кластеризации.
  5. Требования открытости системы: у ИС должны присутствовать открытые интерфейсы для возможной доработки и интеграции с другими системами.

---

1. Разработка проектных решений по программному обеспечению

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

1. Иерархические.
2. Сетевые.
3. Реляционные.

В настоящее время широко применяются реляционные базы данных в связи со следующими факторами [5]:

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

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

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

• Microsoft SQL Server;
• PosgreSQL;
• IBM DB2;
• Oracle database.

СУБД IBM DB2 является кроссплатформенной, обеспечивает стабильную работу базы данных [2]. Недостатками системы являются высокая стоимость и низкая производительность. СУБД Microsoft SQL Server обладает большим пакетом инструментов, стабильностью работы и низкими затратами на администрирование. Недостаток системы заключается в том, что она работает только на платформе Windows. СУБД Oracle обладает высокой производительностью, легкостью интегрирования приложений и устойчивостью к большим потокам данных. Недостатком является высокая стоимость, необходимость приобретения мощного оборудования и персонала для поддержки СУБД.

Ввиду перечисленных свойств реляционных СУБД был сделан выбор в пользу СУБД Oracle, поскольку эта СУБД показывает высокие показатели надежности и масштабируемости.

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

---

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

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

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

1. Проектирование базы данных

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

1. ОКПДТР.
2. ОКЗ.
3. ЕТКС.
4. ЕКСД.
5. ОКВЭД.
6. КЛАДР.
7. Сотрудник.
8. Личное дело.
9. Паспорт.
10. Адрес регистрации.
11. Адрес фактический.
12. Документ об образовании.
13. Табель.
14. Ведомость.
15. Отпуск.
16. Договор.

Для описания взаимосвязей между таблицами построим ER-модель. ER-модель представлена на рисунке 12.

Справочники ОКПДТР, ОКЗ, ЕТКС, ЕСКД и ОКВЭД являются родительскими таблицами по отношению к таблице Личное дело. Связь имеет вид «один-ко-многим», поскольку данные из справочников могут присутствовать во многих таблицах, но в одном личном деле может присутствовать только одна запись из каждого справочника.

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

Справочник КЛАДР является родительской таблицей по отношению к таблицам Адрес регистрации и Адрес проживания. Связь между таблицами имеет вид «один ко многим», поскольку данные таблицы КЛАДР могут присутствовать в адресах разных сотрудников, но каждый адрес является уникальной записью в таблице базы данных.

Таблицы Адрес регистрации и Адрес проживания являются родительскими по отношению к таблице Сотрудник. Связь между таблицами имеет вид «один ко многим», поскольку у одного сотрудника может быть только один адрес регистрации и один адрес проживания, но по одному адресу может проживать несколько сотрудников организации. Также родительской таблицей по отношению к таблице Сотрудник является таблица Паспорт. Связь имеет вид «один к одному», поскольку к конкретного сотрудника может быть только один паспорт, а каждый паспорт может принадлежать только одному сотруднику.

---

Рисунок 12. ER-модель предметной области

Таблица Сотрудник является родительской по отношению к таблицам Отпуск, Табель, Ведомость и Договор. Связь между таблицами имеет вид «один ко многим», поскольку у каждого сотрудника может быть несколько табелей учета рабочего времени, ведомостей по заработной плате, отпусков и договоров. Но все перечисленные объекты могут принадлежать только одному сотруднику.

Характеристика таблиц базы данных представлена в таблице 1.

Таблица 1

Характеристика базы данных

Содержание

Наименование поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Справочник «ОКПДТР»
ID_записи	ID_okpdtr	Счетчик	5	Ключевое поле
Код	Code_okpdtr	Текст	30
Наименование	Name_okpdtr	Текст	100
Справочник «ОКЗ»
ID_ОКЗ	ID_okz	Счетчик	5	Ключевое поле
Код	Code_okz	Текст	30
Наименование	Name_okz	Текст	100
Справочник «ЕТКС»
ID_ЕТКС	ID_etks	Счетчик	5	Ключевое поле
Наименование поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Код	Code_etks	Текст	30
Наименование	Name_etks	Текст	100
Справочник «ЕКСД»
ID_ЕКСД	ID_eksd	Счетчик	5	Ключевое поле
Код	Code_eksd	Текст	30
Наименование	Name_eksd	Текст	100
Справочник «ОКВЭД»
ID_ОКВЭД	ID_okved	Счетчик	5	Ключевое поле
Код	Code_okved	Текст	30
Наименование	Name_okved	Текст	100
Справочник «КЛАДР»
ID_КЛАДР	ID_kladr	Счетчик	5	Ключевое поле
Код	Code_kladr	Текст	30
Город	City_kladr	Текст	100
Область	Obl_kladr	Текст	100
Улица	Str_kladr	Текст	100
Дом	H_kladr	Число	4
Корпус	Corp_kladr	Число	1
Наименование поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Квартира	Kv_kladr	Число	4
Адрес регистрации
ID_адреса	ID_kladr	Счетчик	5	Ключевое поле
ID_kladr	Число	6
Адрес фактический
ID_адреса	ID_kladr	Счетчик	5	Ключевое поле
ID_kladr	Число	6
Справочник «Сотрудник»
ID_сотрудника	ID_sort	Счетчик	5	Ключевое поле
Фамилия	LName_sotr	Текст	30
Имя	Fname_sotr	Текст	30
Отчество	Otch_sotr	Текст	30
Дата рождения	Date_sotr	Дата	8
Пол	Sex_Sotr	Текст	1
Семейное положение	Fam_sotr	Логический	1
Наличие детей	Child_sotr	Логический	1
Документ об образовании
ID_документа	Doc_obr	Счетчик	5	Ключевое поле
Серия	Ser_obr	Текст	2
Номер	Nom_obr	Текст	10
Наименование поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Дата выдачи	Date_obr	Дата/Время	8
Специальность	Sp_obr	Текст	30
Учреждение	Uch_obr	Текст	100
Год выпуска	Year_obr	Числовой	4
Паспорт
ID_паспорта	ID_pasp	Счетчик	5	Ключевое поле
Серия	Ser_pasp	Текст	10
Номер	Nom_pasp	Текст	10
Дата выдачи	Date_pp	Дата/Время	8
Орган выдачи	Org_pasp	Текст	100
Личное дело
ID_дела	ID_del	Счетчик	5	Ключевое поле
Номер	Nom_del	Числовой	6
Дата	Date_del	Дата/Время	8
Табель
ID_табеля	ID_tab	Счетчик	5	Ключевое поле
Дата	Date_tab	Дата	8
Количество часов	Kol_chas	Число	4
Отпуск
ID_отпуска	ID_otp	Счетчик	5	Ключевое поле
Наименование поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Дата начала	Date_otp	Дата	8
Дата окончания	Datok_otp	Дата	8
Ведомость
ID_ведомости	ID_ved	Счетчик	5	Ключевое поле
Номер	Nom_ved	Числовой	30
Дата	Date_ved	Дата	8
Сумма	Sum_ved	Текст	100
Договор
ID_ведомости	ID_dog	Счетчик	5	Ключевое поле
Номер	Num_dog	Числовой	30
Дата	Date_dog	Дата	8
Sod_dog	Текст	30000

---