Проект автоматизированного рабочего места работника отдела кадров (стр. 5 из 14)

Функциональное назначение:

автоматизация процесса учета кадров;

формирование и ведение базы данных работников;

составление отчета в соответствии с данными о работнике;

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

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

Требования к функциональным характеристикам

Проектируемый АРМ должен быть реализован в виде модулей. АРМ должен:

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

осуществлять проверку корректности входных данных.

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

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

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

Требования к надежности

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

Условия эксплуатации

АРМ размещается на диске в виде файлов, готовых к применению при работе компьютера в среде Windows 98/2000. Эргономические показатели должны соответствовать требованиям СниП и ГОСТ по охране труда.

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

температура 10 -30°С;

влажность 10 - 60%.

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

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

Для компьютера, на котором будет работать данный АРМ выдвигаются следующие требования:

CPU Pentium 200

32 Mb RAM

2,1 Gb HDD

манипулятор мышь

монитор

наличие свободного места на винчестере в зависимости от объема базы данных плюс размер программного комплекса;

Требования к информационной и программной совместимости

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

используемая операционная система - Windows98/2000;

наличие BDE;

Требования к программной документации

Предварительный состав программной документации установлен в соответствии с ГОСТ 19.101-77. Ниже приведен список программных документов и их содержание:

описание АРМ- сведения о логической структуре и функционирование АРМ;

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

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

техническое задание - настоящий документ;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для представления информации использована DFD (DataFlowDiagrams) диаграмма потоков данных, иллюстрирующая функции, которые должен выполнять программно-методический комплекс (см. рис.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

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

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