Введение

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

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

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

  1. Исследовать предметную область и выявить ключевые бизнес-процессы, подлежащие автоматизации.
  2. Спроектировать логическую и физическую модель базы данных (БД), способную эффективно хранить всю необходимую информацию.
  3. Обосновать выбор средств реализации и осуществить создание базы данных в выбранной СУБД.
  4. Разработать интуитивно понятный пользовательский интерфейс для взаимодействия с системой.

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

Глава 1. Анализ предметной области и постановка задачи

1.1. Описание предметной области «Учёт персонала магазина»

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

Основные бизнес-процессы, подлежащие автоматизации, включают:

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

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

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

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

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

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

Система должна предоставлять пользователю (менеджеру по персоналу) следующие возможности:

  1. Ведение централизованного справочника сотрудников с созданием и редактированием личных карточек, содержащих всю необходимую персональную и служебную информацию.
  2. Формирование и актуализация штатного расписания магазина.
  3. Учёт отпусков и больничных листов с фиксацией дат начала и окончания.
  4. Осуществление всех базовых CRUD-операций: безопасное добавление новых записей (например, о новом сотруднике), их редактирование (например, при смене фамилии) и удаление (архивация уволенных сотрудников).
  5. Автоматизированное формирование ключевых отчетов: список сотрудников по отделам, график отпусков на заданный период, список юбиляров месяца.

Нефункциональные требования:

  • Надежность: Система должна обеспечивать целостность и сохранность данных, предотвращать потерю информации при сбоях.
  • Производительность: Время отклика системы на основные операции (открытие форм, генерация отчетов) не должно превышать нескольких секунд.
  • Безопасность: Доступ к системе должен быть ограничен. Обработка данных должна вестись в строгом соответствии с законодательством РФ, в частности с ФЗ «О персональных данных».
  • Соответствие законодательству: Все операции и хранимые данные должны соответствовать нормам Трудового кодекса РФ.
  • Юзабилити: Пользовательский интерфейс должен быть интуитивно понятным и не требовать от пользователя длительного специального обучения.

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

Глава 2. Проектирование информационной системы

2.1. Обоснование выбора средств реализации

Выбор инструментария для разработки является стратегическим решением, которое влияет на весь дальнейший процесс. Для данной курсовой работы были рассмотрены два основных варианта: использование электронных таблиц MS Excel и системы управления базами данных (СУБД) MS Access.

MS Excel является мощным инструментом для работы с табличными данными, однако для нашей задачи он имеет существенные недостатки. Главный из них — отсутствие полноценной поддержки реляционной модели данных. Попытка связать несколько таблиц (например, «Сотрудники» и «Отпуска») в Excel приводит к дублированию информации и сложностям с обеспечением ее целостности. Кроме того, Excel плохо подходит для организации многопользовательского доступа и разграничения прав.

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

  • Интегрированная среда: Access предоставляет единый инструмент для проектирования структуры базы данных, создания форм для ввода и редактирования данных, а также конструирования отчетов.
  • Простота освоения: По сравнению с более мощными СУБД (такими как MS SQL Server или Oracle), Access имеет низкий порог вхождения, что идеально для курсовой работы.
  • Достаточная функциональность: Возможностей Access более чем достаточно для реализации всех функциональных требований, включая обработку связанных таблиц и разработку удобного пользовательского интерфейса.

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

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

2.2. Построение концептуальной модели в нотации IDEF0

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

Центральным элементом является контекстная диаграмма верхнего уровня A-0 «Автоматизировать учет персонала магазина». Она описывает систему как «черный ящик», взаимодействующий с внешней средой.

Компоненты этой диаграммы следующие:

  • Вход (Input): Информация, которая поступает в систему для обработки. Сюда относятся данные о соискателях, заявления от действующих сотрудников (на отпуск, увольнение), информация о вакансиях.
  • Управление (Control): Правила и ограничения, регламентирующие работу системы. Главными управляющими воздействиями являются Трудовой кодекс РФ и ФЗ «О персональных данных», а также внутренние приказы директора магазина и должностные инструкции.
  • Выход (Output): Результаты работы системы. Это сформированные отчеты (график отпусков, списки сотрудников), приказы, а также обновленная и структурированная база данных персонала.
  • Механизм (Mechanism): Ресурсы, выполняющие работу. В нашей системе это Менеджер по персоналу (пользователь) и непосредственно сама СУБД MS Access (техническое средство).

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

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

2.3. Разработка логической и физической модели базы данных

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

Логическая модель

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

  • Employees (Сотрудники): Основная таблица для хранения личных данных. Поля: EmployeeID (ключ), LastName, FirstName, BirthDate, PassportData, Address, PhoneNumber, PositionID (внешний ключ), DepartmentID (внешний ключ).
  • Positions (Должности): Справочник должностей. Поля: PositionID (ключ), PositionName, Salary.
  • Departments (Отделы): Справочник отделов магазина. Поля: DepartmentID (ключ), DepartmentName.
  • Vacations (Отпуска): Таблица для учета отпусков. Поля: VacationID (ключ), EmployeeID (внешний ключ), StartDate, EndDate.

Связи между таблицами

Ключевым элементом реляционной модели являются связи. На ER-диаграмме (схеме данных) они показывают, как таблицы логически соединены друг с другом:

  • Связь «один-ко-многим» между `Departments` и `Employees`: в одном отделе может работать много сотрудников, но каждый сотрудник приписан только к одному отделу.
  • Аналогичная связь «один-ко-многим» между `Positions` и `Employees`: одну должность могут занимать несколько сотрудников.
  • Связь «один-ко-многим» между `Employees` и `Vacations`: у одного сотрудника может быть много записей об отпусках, но каждая запись об отпуске относится только к одному сотруднику.

Такая структура позволяет избежать дублирования данных и обеспечивает их целостность. Например, нельзя удалить отдел из таблицы `Departments`, если в нем числятся сотрудники.

Физическая модель

Физическая модель является прямой реализацией логической модели в среде выбранной СУБД. В нашем случае она будет создана в MS Access. Типы данных для полей будут выбраны в соответствии с возможностями Access (например, «Текстовый», «Дата/Время», «Числовой», «Счетчик» для первичных ключей).

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

Глава 3. Реализация и тестирование системы

3.1. Создание таблиц и связей в среде MS Access

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

Создание таблиц происходит в режиме «Конструктор». На примере таблицы `Employees` процесс выглядит следующим образом:

  1. Открывается MS Access и создается новая пустая база данных.
  2. В режиме конструктора создается новая таблица `Employees`.
  3. Последовательно добавляются все поля, спроектированные на предыдущем этапе: `EmployeeID`, `LastName`, `FirstName` и так далее.
  4. Для каждого поля задается соответствующий тип данных. Например, для `EmployeeID` выбирается тип «Счетчик», что автоматически делает его уникальным первичным ключом. Для `LastName` — «Короткий текст», для `BirthDate` — «Дата/время».

Аналогичным образом создаются все остальные таблицы: `Departments`, `Positions`, `Vacations`. После создания всех таблиц необходимо установить между ними связи для обеспечения целостности данных. Это делается в специальном окне «Схема данных». Путем перетаскивания поля первичного ключа (например, `DepartmentID` из таблицы `Departments`) на поле внешнего ключа (поле `DepartmentID` в таблице `Employees`) устанавливается связь «один-ко-многим». При создании связи MS Access предлагает включить опцию «Обеспечение целостности данных», что является критически важным для корректной работы базы.

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

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

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

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

  • «Сотрудники» — открывает форму для просмотра и редактирования данных о персонале.
  • «Отделы и должности» — открывает формы для редактирования соответствующих справочников.
  • «Отчеты» — открывает меню для выбора и формирования отчетов.
  • «Выход» — закрывает приложение.

Наиболее детально проработана форма «Карточка сотрудника». Она спроектирована для максимально удобной работы с данными. На форме размещены поля для ввода всей необходимой информации (ФИО, дата рождения, адрес). Для выбора отдела и должности используются выпадающие списки, которые подгружают значения из связанных таблиц `Departments` и `Positions`. Это исключает ошибки ручного ввода. Также на форме присутствуют управляющие кнопки: «Добавить нового», «Сохранить изменения», «Удалить запись».

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

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

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

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

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

С помощью инструмента «Мастер отчетов» в MS Access были созданы несколько ключевых отчетов:

  • «Список сотрудников по отделам»: отчет, который группирует всех сотрудников по их отделам, позволяя быстро оценить состав каждого подразделения.
  • «График отпусков на месяц»: отчет, который по запросу пользователя (выбор месяца и года) формирует список сотрудников, уходящих в отпуск в указанный период.

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

  1. Добавление нового сотрудника: Проверка корректности сохранения всех введенных данных через форму «Карточка сотрудника».
  2. Редактирование данных: Изменение фамилии и должности существующего сотрудника и проверка, что изменения отразились в базе.
  3. Проверка целостности связей: Попытка удалить отдел, в котором числятся сотрудники. Система должна корректно выдать ошибку и запретить операцию.
  4. Корректность формирования отчета: Сверка данных в отчете «График отпусков» с данными, введенными в таблицу `Vacations`.

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

Разработка и тестирование завершены, что позволяет сделать общие выводы по всей курсовой работе.

Заключение

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

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

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

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

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

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

Похожие записи