Разработка программного обеспечения системы «Автоматизированная система подготовки и принятия кадровых решений» в МО «Горнозаводский м

 

Рисунок 2.9. Алгоритм просмотра личных данных администратором

 

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

 

Рисунок 2.10. Алгоритм редактирования личных данных администратором

 

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

 

 

 

 

 

 

 

 

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

2.2.3.Цель функционирования информационной системы.

 

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

 

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

Выбор СУБД – один из ключевых моментов в разработке программного приложения. Важно выбрать такую базу данных, которая бы в наибольшей степени соответствовала предъявленным к подсистеме требованиям. [1]

На выбор влияют следующие факторы:

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

 

2.2.5. Выбор среды разработки программного приложения

Для разработки интерфейса и реализации доступа к БД используется Borland Delphi 7. Система Delphi позволяет быстро и эффективно разрабатывать самые разнообразные приложения, включая и приложения для работы с базами данных. В качестве средства разработки была выбрана среда разработки Delphi версии 7.0 фирмы Borland. Это позволило сократить время на разработку программы за счет использования стандартных компонентов VCL, а также создать высокопроизводительное легко переносимое приложение и связать его с базой данных.

 

 

2.2.6. Постановка задачи

Целью дипломной работы является разработка программного обеспечения системы подготовки и принятия кадровых решений на примере МО «Горнозаводский муниципальный район» с использованием существующей базы данных, обрабатываемой средствами FoxPro.

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

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

 

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

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

База данных «Кадры» разрабатывается для хранения текстовой информации (хотя для удобства ввода некоторые поля таблиц – числовые), поэтому в приложении не будут применены вычисления введенных оператором данных.

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

Отделу кадров необходимо решать следующие задачи:

Регистрация новых сотрудников.

Уточнение данных по существующим сотрудникам.

Удаление сотрудников.

Опишем задачи, заполнив рабочий бланк №1.

В качестве имен элементов/объектов подберем краткий английский перевод описания этих элементов/объектов, представленных в Приложении «РАБОЧИЙ БЛАНК №1 ОПИСАНИЯ ЗАДАЧ».

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

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

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

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

Опишем используемые объекты, заполнив рабочий бланк №2, ( см. Приложение «РАБОЧИЙ БЛАНК №2 (ОБЪЕКТЫ)»).

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

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

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

Правило 1: Каждое поле любой таблицы должно быть уникальным.

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

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

Правило 4: Должна иметься возможность изменять значения любого поля (не входящего в первичный ключ), и это не должно повлечь за собой изменение другого поля.[2]

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

 Опишем базу данных в табличной  форме в приложении «ОПИСАНИЕ ТАБЛИЦ БАЗЫ ДАННЫХ «КАДРЫ»».

Итак, спроектировано 11 таблиц базы данных «Кадры». Для удобства работы, 10 из них следует проиндексировать:

таблицу STUFF.DBF по полю ORG_NUM;

таблицу EDUCAT.DBF по полю DATE_BEGIN;

таблицу LANGUAGE.DBF по полю OTH_LANG;

таблицу CONVICT.DBF по полю DATE_VERD;

таблицу FAMILY.DBF по полю DATE_RELAT;

таблицу WORKCARD.DBF по полю DATE_WRK;

таблицу MOVING.DBF по полю DATE_MOV;

таблицу QUALIFIC.DBF по полю DATE_QUAL;

таблицу BUS_TRIP.DBF по полю START_TRP;

таблицу HOLIDAY.DBF по полю WITH_HOL.

 

2.3. Реализация системы

2.3.1.Общие требования к системе

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

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

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

Требования к пользовательскому интерфейсу

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

Интерфейс должен удовлетворять следующим требованиям:

• обеспечивать идентификацию пользователя (используются “слепые” пароли, т.е. при наборе пароля его символы не показываются на экране либо заменяются одним типом символов);
• обеспечивать минимум усилий и временных затрат пользователей для навигации по подсистеме;
• размер главной и дочерних форм должны быть 800х600 или 1024х786 точек;
• главная форма должна содержать основные данные и разнообразные фильтры для поиска информации.

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

Согласно документу «Общие рекомендации по разработке приложений в Delphi 7 для программистов администрации МО клиентская часть подсистемы должна удовлетворять следующим требованиям:

1. Использование дополнительных компонентов:
1. EhLib – библиотека включает в себя компоненты и классы для Borland Delphi и предназначена для расширения функциональности клиентской части приложений, работающей с БД: вывод, печать и занесения данных конечным пользователем.
2. XLReport – средство построения отчетов и анализа данных в Delphi-приложениях с использованием Microsoft Excel.

      Именования файла проекта и форм:

3. В названиях рекомендуется использовать английские слова и их сокращения, например: отчет – report, rep; добавление – add; редактирование – edit; удаление – del и т.д.
4. Имя программы совпадает с названием проекта, например: Balance (Баланс).
5. Имена файлов формы должны быть информативными и содержать сведения о назначении, например: dm_ross (модуль данных ведения россыпи); f_add_spec (форма добавления спецификации) и т.д.
2. Именование компонентов:
1. Имена компонентов должны быть информативными, при этом целесообразно включать в имя данные о типе компонента и его назначении в приложении.
2. Избегать имен, формируемых по умолчанию средой разработки Delphi 7.
3. Общая архитектура приложения:
1. Главная форма должна содержать основную информацию для просмотра данных приложения, выходы в режимы ведения данных, формирования отчетных форм, поиска и фильтрации данных.
2. Модуль данных должен содержать не визуальные компоненты, используемые для доступа к данным.
3. Дочерние формы должны содержать функции ведения данных, ведения справочников и т.д.

 

Согласно документу «Соглашение по ведению структуры БД» серверная часть подсистемы должна удовлетворять следующим требованиям:

1. Именование таблиц, представлений и последовательностей:
1. Имена таблиц должны начинаться с префикса предметной области (проекта).
2. При создании таблицы является обязательным указание в примечании назначения данной таблицы.
3. Временные таблицы имеют префикс “TMP_”.
4. Имена представлений имеют префикс “VW_”.
5. Имена последовательностей имеют префикс “SQ_”.
2. Именование полей таблиц:
1. Имена первичных ключей начинаются с префикса “PK_”.
2. Для каждого поля необходимо указывать, если это возможно, длину и опцию NULL.
3. Для каждого поля  является обязательным указание в примечании назначения данного поля таблицы.
3. Именование пакетов, процедур и функций:
1. Имена пакетов должны начинаться с префикса “PCK_”.
2. Имена функций должны начинаться с префикса “F_”.
3. Имена процедур должны начинаться с префикса “P_”.

Имена пакетов, процедур и функций должны содержать наименование предметной области (проекта).

Личные карточки

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

Главная. В нем заносятся и отображаются метрические данные сотрудника – Ф.И.О., дата рождения, семейное положение, номер паспорта, группа инвалидности и т.д. Также заносится его стаж и табельный номер внутри предприятия.

Кроме основной закладки «Главная» созданы еще следующие разделы

• Образование,
• Заграница
• Аттестация
• Награды и поощрения
• Почетные звания
• Поощрения по заводу
• Взыскания
• Работа по совместительству
• Отпуска
• Назначения и перемещения
• Последнее место работы
• Увольнение
• Воинский учет.