Разработка автоматизированного рабочего места сотрудника кадрового отдела банка

Технико-экономическая  эффективность

Экономическим преимуществом  данного АРМ является сокращение затрат на ведение документации и  экономия рабочего времени.

Стадии и этапы разработки

Разработка ведется  в несколько этапов в соответствии с ГОСТ 19.101-77:

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

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

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

разработка форм приложения;

разработка алгоритмов доступа к данным и обработки  информации;

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

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

Порядок контроля

Контроль программного продукта осуществляется в следующем порядке:

Проверка запуска программы.

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

Проверка контроля вводимой информации.

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

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

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

Проверка корректности завершения работы программы.

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

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

2. Разработка структуры  АРМ

2.1 Анализ и автоматизация  информационных потоков

 

 

2.1.1 Построение диаграммы  потоков данных (DFD - диаграмма)

Для представления информации использована DFD (Data Flow Diagrams) диаграмма  потоков данных, иллюстрирующая функции, которые должен выполнять программно-методический комплекс (см. рис.2.1). Она идентифицирует внешние сущности, а также единственный процесс, отражающий главную цель системы

Рисунок 2.1 - Контекстная DFD - диаграмма

Внешние сущности: Работник ОК и БД.

Основной процесс - Обработать, обрабатывает данные о работниках.

Потоки данных, которыми обменивается проектируемая система с внешними объектами: Работник ОК вводит данные о новых работниках или изменившиеся данные существующих работников, данные трудовой книжки. БД хранит информацию о работниках, а также получает запросы и посылает данные по запросу процессу Обработать. Работнику ОК поступает личная карточка работника, стаж работника (общий и непрерывный).

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

Рисунок 2.2 - Детализирующая DFD - диаграмма

Процесс 1.1 Осуществляет ввод информации о новых работниках и имеет на входе и выходе потоки.

Входной поток - Данные о новых работниках, который содержит данные о новых работниках;

Выходной поток - Информация о новых работниках, который передает информацию о новых работниках в хранилище данных;

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

Входной поток - Данные по запросу, получение данных в результате обращения к БД;

Выходной поток - Запрос к БД, обращение к БД, в случае редактирования данных;

Выходной поток - Стаж работника, содержит рассчитанный стаж работника (общий и непрерывный);

Выходной поток - Запрос на печать, посылает запрос на печать личной карточки;

Выходной поток - Запрос на просмотр, посылает запрос на просмотр личной карточки;

Процесс 1.3 Осуществляет выдачу отчета.

Входной поток - Запрос на отчет, посылается запрос на получение отчета;

Входной поток - Запрос на печать, посылает запрос на печать личной карточки;

Входной поток - Запрос на просмотр, посылает запрос на просмотр личной карточки;

Входной поток - Требуемые для отчета данные, содержит требуемую для отчета информацию;

Выходной поток - Личная карточка, выдача личной карточки

 

 

2.2 Разработка компонентов  АРМ

 

 

2.2.1 Логическая модель  АРМ для моделирования ПО

Построение STD

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

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

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

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

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

После закрытия "Личные данные персонала" и "Общих справочников" переход в состояние "Ожидание действия пользователя". При нажатии "Файл" - Выход, переходим в конечное состояние.

Рисунок 2.3 -SDT – диаграмма

Построение ER - диаграммы

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

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

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

R1 (Место_работы_, Табельный  _номер, Должность_ID, Отдел_ID, Дата_поступления,  Дата_увольнения, Статья).

R2 (Отдел_ID, Название_отдела).

R3 (Должность_ID, Название_должности).

R4 (Национальность_ID, Название_национальности)

R5 (Место_учебы_ID, Тип,  Название).

R6 (Табельный_номер, Фамилия,  Имя, Отчество).

R7 (Город_ID, Название_города).

R8 (Партия_ID, Название_партии).

R9 (Табельный номер,  Отдел_ID, Должность_ID, Город_ID, Партия_ID, Национальность_ID, Место_образования_ID, Дата_рождения, Место_рождения, Адрес, Специальность, Квалификация, Номер_диплома, Дата_получения, Серия_паспорта, Номер_паспорта, Кем_выдано, Профсоюз, Семья);

R10 (Отдел_ID, Место_работы_).

R11 (Отдел_ID, Должность_ID, Табельный_номер, Дата_назначения).

 

Рисунок 2.4 - ER - Диаграмма

 

 

2.2.2 Разработка физической  модели АРМ

Разработка схемы структуры реляционной базы данных

В соответствие с полученным набором отношений, спроектируем структуру  таблиц базы данных. Структуры таблиц с указанием наименований, типов, размеров полей и указанием ключей приведены в таблицах 2.1-2.11

Структура таблицы Main_Cart. db представлена в таблице 2.1

Таблица 2.1 Main_Cart. db

Тип поля	Название	Размер
IntegerField	'TabNo'
IntegerField	'Dep_ID'
IntegerField	'Dolgnost_ID'
IntegerField	'Town_ID'
IntegerField	'Partia_ID'
IntegerField	'Nation_ID'
IntegerField	'Obr_Place_ID'
IntegerField	'Bplace_ID'
DateField	'BDate'
StringField	'Address'	200
StringField	'Spec_in_Dipl'	100
StringField	'Qualify'	50
StringField	'DiplNo'
TdateField	'DiplDate'
StringField	'Passport_Ser'	2
IntegerField	'Passport_No'
StringField	'Passport_Get_Place'	40
BooleanField	'Profsouz'
MemoField	'Famely'	240

Структура таблицы WorkPlace. db представлена в таблице 2.2

Таблица 2.2 WorkPlace. db

Тип поля	Название	Размер
AutoIncField	'WP_ID'
IntegerField	'TabNo'
IntegerField	'Dep_ID'
IntegerField	'Dolgnost_ID'
DateField	'Date_IN'
DateField	'Date_OUT'
StringField	'Stat_OUT'	30

Структура таблицы department. db представлена в таблице 2.3

Таблица 2.3 department. db

Тип поля	Название	Размер
AutoIncField	'Dep_ID'
StringField	'Dep_Name'	70

Структура таблицы dolgnost. db представлена в таблице 2.4

 

Таблица 2.4 dolgnost. db

Тип поля	Название	Размер
AutoIncField	'Dolgnist_ID'
StringField	'Dolgnost_Name'	70

Структура таблицы nation. db представлена в таблице 2.5

Таблица 2.5 nation. db

Тип поля	Название	Размер
AutoIncField	'Nation_ID'
StringField	'Nation_Name'	50

Структура таблицы Obr_Place. db представлена в таблице 2.6

Таблица 2.6 Obr_Place. db

Тип поля	Название	Размер
AutoIncField	'Obr_Place_ID'
StringField	'Obr_Place_Type'	50
StringField	'Obr_Place_Name'	150

Структура таблицы Persen. db представлена в таблице 2.7

Таблица 2.7 Persen. db

Тип поля	Название	Размер
IntegerField	'TabNo'
StringField	'F’	40
StringField	'I’	40
StringField	'O’	40

Структура таблицы town. db представлена в таблице 2.8

Таблица 2.8 town. db

Тип поля	Название	Размер
AutoIncField	'Town_ID'
StringField	'Town_Name'	70

Структура таблицы partia. db представлена в таблице 2.9

Таблица 2.9 partia. db

Тип поля	Название	Размер
AutoIncField	'Partia_ID'
StringField	'Partia_Name'	100

Структура таблицы G_Dep. db представлена в таблице 2.10

Таблица 2.10 G_Dep. db

Тип поля	Название	Размер
IntegerField	'ID_WG'
IntegerField	'ID_Dep'

Структура таблицы Pers_Group. db представлена в таблице 2.11

Таблица 2.11 Pers_Group. db

Тип поля	Название	Размер
IntegerField	'ID_Dep'
IntegerField	'ID_Dol'
IntegerField	'TabNo'
IntegerField	'Date'