Система автоматизации расчета заработной платы

Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования

«Пермская государственная сельскохозяйственная академия им. академика Д.Н. Прянишникова»

Кафедра: информационных технологий и автоматизированного проектирования

курсовой проект

по дисциплине: «Проектирование ИС»

на тему: «Система автоматизации расчета заработной платы»

Выполнил: студент 6 курса факультета заочного отделения специальности «Прикладная информатика (в экономике)»

Халик Алексей Александрович Пермь 2015

Техническое задание на создание автоматизированной системы

1. Общие сведения

1.1.Полное наименование системы: Разработка информационной системы для автоматизации расчета заработной платы (далее «ЗП»).

1.2.Исполнитель: студент факультета Прикладной информатики Специальности 80 801 группы ПП-2010 Халик Алексей Александрович.

1.3. Перечень документов, на основании которых создается система, кем и когда утверждены эти документы:

Учебный план по дисциплине «Проектирование информационных систем», методическое пособие по курсовому проектированию «Проектирование информационных систем», задание на курсовое проектирование.

2. Назначение и цели создания системы

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

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

3. Характеристика объектов автоматизации

3.1. Объектом автоматизации является деятельность бухгалтерии, в том числе расчет удержаний за прогулы, начисления по больничным листам, расчет НДФЛ, рассчет конечной заработной платы.

3.2. Система «ЗП» должна работать в операционной системе Windows Xp, Vista, 7. Обслуживание системы должно осуществляться сотрудниками бухгалтерии и администратора, в обязанности которых будет входить ввод новой информации, отслеживание в целом за работой системы, устранение неполадок и другие.

Система «ЗП» проходит реализацию в ОС Windows 7, так как эта модель Windows широко распространена, имея ряд достоинств:

— Многозадачность;

— Совершенство пользовательского интерфейса;

— Устойчивость в работе;

Основной ОС, действующей на предприятии, являются ОС класса Windows. В настоящий момент времени на объекте автоматизации бизнес-процесс документооборота не автоматизирован.

4. Требования к системе

4.1.Требования к системе в целом. Основное требование к системе «ЗП» заключаются в автоматизации деятельности отдела кадров. Она должна обеспечить:

— ввод и хранение данных обо всех сотрудниках (табельный номер сотрудника, должность, фамилия, имя, отчество и др.);

— должно допускаться редактирование введённой ранее информации;

— система должна быть интуитивно понятной в использовании;

— система предназначена для использования бухгалтером;

4.2.Требования к пользователям системы. Пользователями системы являются сотрудники бухгалтерии. Сотрудникам для работы с системой «ЗП» необходимо иметь навыки работы на ПК.

4.3. Требования к надежности системы. Для обеспечения высокой надежности функционирования как системы в целом, так и её отдельных компонентов должно обеспечиваться выполнение следующих требований: — соблюдения правил эксплуатации и технического обслуживания программно-аппаратных средств;

— обязательного применения на рабочих местах источников бесперебойного питания с возможностью автономной работы системы не менее 5 минут;

— предварительного обучения пользователей и обслуживающего персонала;

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

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

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

4.5. Требования к программной и информационной совместимости. Разрабатываемая система должна работать под управлением операционной системы Windows Xp, Vista, 7.

4.6. Требования к техническим средствам. Технические средства должны включать рабочие станции с характеристиками не ниже:

— процессор Intel Pentium IV 2,4 GHz и выше;

— объём необходимой оперативной памяти 1024 Mb и выше;

— объем жесткого диска не менее 20 GB;

5. Состав и содержание работ по созданию системы При выполнении данной работы необходимо разработать:

5.1. Техническое задание на проектирование Выполняется по ГОСТ 34. 602−89. Техническое задание на создание автоматизированной системы «ЗП». При этом заполняются следующие разделы (и их подразделы): 1) общие сведения; 2) назначение и цели создания (развития) системы; 3) характеристика объектов автоматизации; 4) требования к системе; 5) состав и содержание работ по созданию системы.

5.2.

Введение

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

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

Системный анализ проводится с целью:

1) выяснения потребностей заказчика;

2) оценки выполнимости системы;

3) выполнения экономического и технического анализа;

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

5) определения стоимости и ограничений планирования;

6) создания системной спецификации.

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

Анализ требований дает возможность:

1) определить функции и характеристики программного продукта;

2) обозначить интерфейс продукта с другими системными элементами;

3) определить проектные ограничения программного продукта;

4) построить модели: процесса, данных, режимов функционирования продукта;

5) создать такие формы представления информации и функций системы, которые можно использовать в ходе проектирования.

В пояснительную записку включаются:

— схема, позволяющая определить рамки системы;

— перечень исполнителей и их задач;

— перечень исполнителей и их задач на основе анализа внешних;

— перечень элементарных бизнес-процессов и соответствующих им прецедентов;

— все прецеденты в сжатом формате;

— один прецедент в развернутом описании или «контрольный» прецедент;

— диаграмма прецедентов;

— диаграмма последовательностей для сценария «контрольного» прецедента;

— описания системных операций для «контрольного» прецедента;

— дополнительная спецификация;

— документ «Видение»;

— документ «Словарь терминов».

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

Состав модели предметной области:

— Объекты предметной области (или концептуальные классы);

— Ассоциации между концептуальными классами;

— Атрибуты концептуальных классов;

— Модель предметной области.

5.5. Модель проектирования Это набор диаграмм, описывающих логику проектного решения.

Состав модели проектирования:

— диаграммы взаимодействия;

— диаграмма последовательностей;

— диаграмма кооперации;

— диаграмма (программных) классов (и интерфейсов).

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

5.7. Модель реализации Состав модели реализации:

— Выбор языка программирования;

— Преобразование результатов проектирования в программный код;

— Создание определений классов на основе диаграмм классов;

— Определение класса с методами и простыми атрибутами;

— Добавление атрибутов — ссылок;

— Создание методов на основе диаграмм взаимодействия;

— Порядок реализации классов (от min связанных с другими классами);

— Основное программное решение.

5.8.

Заключение

В заключении делаются выводы по проекту, определяются пути его внедрения и направления дальнейшего совершенствования системы «ЗП».

1. Системный анализ и анализ требований

1.1 Диаграмма прецедентов

1.2 Определение прецедентов

1.3Диаграмма прецедентов

1.4 Дополнительная спецификация

1.5 Видение

1.6 Словарь терминов

1.7 Диаграмма последовательности

2. Модель предметной области

2.1 Объекты предметной области

3. Модель проектирования

3.1 Диаграмма последовательностей

3.2 Диаграмма кооперации

3.3 Диаграмма классов

4. Модель данных

5. Модель реализации

Заключение

Список источников

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

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

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

Задачей курсового проекта является проектирование системы «ЗП» для автоматизации деятельности бухгалтерии по расчету удержаний за прогулы, начислений по больничным листам, расчету НДФЛ, рассчету конечной заработной платы.

Объектом исследования является деятельность бухгалтерии. Необходимо провести системный анализ и анализ требований, на основе которых мы должны получить модель предметной области, модель проектирования, модель данных и модель реализации с ипользованием case-технологии CASEBERRY, поддерживающей стандартный язык моделирования UML.

1. Системный анализ и анализ требований

Предметной областью является деятельность бухгалтерии.

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

1.1 Диаграмма прецедентов Для того чтобы создать один из артефактов при определении требований к АСУ — диаграмму прецедентов, необходимо определить рамки системы, а также исполнителей и их задачи. Результат можно посмотреть на рисунке 1 и в таблице

Рисунок 1. Основные исполнители и их задачи при определении рамок системы

1.2 Определение прецедентов Введем некоторые определения.

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

Сценарий — это специальная последовательность действий или взаимодействий между исполнителями и системой.

Таблица 1 — Перечень исполнителей и их задач

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

Таблица 2 — Перечень исполнителей и их задач на основе анализа внешних событий

Описание всех прецедентов в сжатом формате Описания прецедентов — это текстовые документы, а не диаграммы.

Моделирование прецедентов — это процесс написания текста, а не рисования. Однако для иллюстрации имен прецедентов и исполнителей, а также их взаимоотношений в UML определены обозначения для диаграммы прецедентов.

П1 — Ведение БД сотрудников Бухгалтер внесение информации о сотрудниках и поддержание актуальности данных П2 — Расчет удержаний за прогулы Бухгалтер рассчитывает размер удержаний за дни, которые работник пропустил по неуважительной причине.

П3 — Расчет начислений по больничным листам Бухгалтер рассчитывает размер начислений за дни, которые сотрудник пропустил в связи с болезнью. Количество дней подтверждается листком о временной нетрудоспособности.

П4 — Расчет НДФЛ Бухгалтер рассчитывает налог на доходы физических лиц (НДФЛ) П5 — Расчет окончательной заработной платы Бухгалтер рассчитывает окончательную сумму заработной платы с учетом всех начислений и удержаний Описание прецедента «Расчет окончательной заработной платы» в развернутом формате Основной успешный сценарий (или основной процесс)

1. Бухгалтер создает новый документ

2. Бухгалтер выбирает график рабочего времени

3. Бухгалтер выбирает сотрудника

4. Бухгалтер выбирает отдел

5. Бухгалтер выбирает должность

6. Бухгалтер вводит год, месяц

7. Бухгалтер вводит сумму удержаний за прогулы

8. Бухгалтер вводит сумму начислений по больничному листу

9. Бухгалтер вводит сумму удержания НДФЛ

10. Бухгалтер вводит сумму конечной заработной платы

11. Бухгалтер сохраняет документ Расширения (или альтернативные потоки)

1. Система определяет аномалию, повлекшую сбой.

— Система уведомляет об ошибке бухгалтера, регистрирует ошибку и переходит в начальное состояние.

— Бухгалтер начинает оформление новой записи.

2. Не заполнен один из пунктов документа.

— Система уведомляет об ошибке.

— Бухгалтер вносит изменения.

1.3 Диаграмма прецедентов В языке UML существует система обозначений для диаграммы прецедентов, иллюстрирующей имена прецедентов, исполнителей и взаимосвязи между ними (рисунок 2).

Все сущности, включая разрабатываемую систему, могут играть различные роли.

1.4 Дополнительная спецификация Введение В этом документе описаны все требования к системе «ЗП — система» не вошедшие в описание прецедентов.

Рисунок 2. Диаграмма прецедентов.

Функциональность Регистрация событий и обработка ошибок Все ошибки регистрируются на постоянном носителе.

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

Подключаемые бизнес — правила

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

Удобство использования Человеческие факторы Пользователь системы будет постоянно работать с монитором, поэтому необходимо следующее:

— Текст должен быть легко читаемым.

— Нужно избегать мерцающих цветов.

Быстрая, простая и корректная обработка информации — главные принципы системы автоматизации.

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

Производительность Нам необходимо произвести расчеты заработной платы и сохранить эти расчеты в системе, поэтому нам необходимо производить этот процесс быстро. Наша задача — выполнить операции за минимальное время.

Возможности поддержки Адаптация системы Различные пользователи ЗП-системы могут устанавливать свои бизнес-правила для обработки данных о клиентах. Поэтому в нескольких заранее определенных точках сценария (например, при добавлении нового клиента) нужно обеспечить возможность подключения бизнес-правил.

Конфигурирование Сетевые конфигурации различных, пользователей ЗП-системы могут отличаться. Могут использоваться архитектуры «тонкого» и «толстого» клиентов, двухуровневые и многоуровневые архитектуры и т. д. Кроме того, конфигурация ресурсов каждого клиента может изменяться со временем, отражая производственные потребности и потребности в производительности. Следовательно, система должна быть настраиваемой и отражать потребности пользователей. Этот вопрос требует тщательной дополнительной проработки, изучения степени гибкости и способов ее достижения.

Интерфейсы Важные интерфейсы и аппаратные средства

— принтер для печати зарплатных ведомостей;

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

Бизнес-правила Бизнес-правила представлены в таблице 3.

Таблица 3 — Бизнес-правила

Вопросы законодательства

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

Необходимо учитывать все изменения в БД. Обновление БД ЗП-системы могут изменяться достаточно часто.

Информация из предметной области

Обновление БД

БД может обновляться и корректироваться достаточно часто. Поэтому желательно возложить задачу обновления БД ЗП-системы на отдельную программу.

Критерии поиска

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

1.5 Видение

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

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

Место системы Система предназначена для бухгалтера организации.

Заинтересованные лица

Пользователи системы Основным заинтересованным лицом будет являться предприятие.

Бухгалтер: оформляет расчеты заработной платы.

Таблица 4 — Преимущества системы

Основные свойства системы

Как было упомянуто выше, свойства системы описываются сжато путем перечисления основных функций:

· хранение в системе всех расчетов заработной платы;

· системное администрирование и управление пользователями, безопасностью, таблицами и т. д.;

· автоматический переход в автономный режим работы при выходе из строя внешних систем.

1.6 Словарь терминов В словарь терминов (glossary) включаются термины и определения. Он также может служить словарем данных.

Таблица 5 — Определения

1.7 Диаграмма последовательности Прецеденты определяют, как исполнители взаимодействуют с программной системой. В процессе этого взаимодействия исполнителем генерируются события, передаваемые системе, которые представляют собой запросы на выполнение некоторой операции.

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

Рисунок 3. Диаграмма последовательности на основе основного успешного сценария в развернутом формате описания прецедента Описание системных операций диаграммы последовательности Описания Системных операций (system operation contract) описывают детальное поведение системы в терминах изменения состояния объектов модели предметной области после выполнения системных операций.

Описания определяются для системных операций (system operations).

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

Таблица 1 Разделы описания

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

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

Идентификация классов понятий или концептуальных классов — составная часть исследования предметной области. Модели предметной области на языке UML строятся в форме диаграмм классов.

2.1 Объекты предметной области

Концептуальные классы (или объекты предметной области) данной предметной области изображены на рисунке 4.

Рисунок 4 — Исходная модель предметной области Модель предметной области широко используется в качестве основы для разработки программных объектов и обеспечивает важную входную информацию для создания нескольких последующих артефактов.

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

Идентификация классов понятий или концептуальных классов — составная часть исследования предметной области. Модели предметной области на языке UML строятся в форме диаграмм классов.

Рисунок 5 — Модель предметной области

3. Модель проектирования

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

· Диаграммы кооперации (collaboration diagram)

· Диаграммы последовательностей (sequence diagram)

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

3.1 Диаграмма последовательностей Диаграммы последовательностей (sequence diagram) иллюстрируют взаимодействие в форме. Здесь объекты располагаются слева направо.

Рисунок 6 — Диаграмма последовательности

3.2 Диаграмма кооперации Диаграммы кооперации (collaboration diagram) иллюстрируют взаимодействие объектов в формате графа или сети. При этом объекты могут размещаться в любом месте диаграммы.

Рисунок 7 -Диаграмма кооперации

3.3 Диаграмма классов Диаграмма классов (design class diagram) иллюстрирует спецификации программных классов и интерфейсов (например, интерфейсов Java, С# и т. д.) в приложении. Обычно на такую диаграмму выносится следующая информация:

- Классы, ассоциации и атрибуты;

- Интерфейсы со своими операциями и константами;

- Методы;

- Информация о типах атрибутов;

- Способы навигации;

- Зависимости.

На диаграмме классов показана дополнительная информация о типах параметров (рис. 8).

Рисунок 8 — Диаграмма классов

4. Модель данных

Логическая модель данных представлена на рисунке 9.

Рисунок 9 — Логическая модель данных

5. Модель реализации

Чтобы модуль генерации кода Caseberry мог сгенерировать приложение, использовалось быстрое прототипирование. В результате создания прототипа, настройки приложения, настройки генератора скриптов для БД, настройки модуля кодогенерации, создания структуры данных и сборки было получено работающее приложение с названием «АО».

Рисунок 10 — Диаграмма классов, полученная путем быстрого прототипирования.

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

Рисунок 11 — Экранные формы Рисунок 12 -Экранная форма «Бухгалтер»

Рисунок 13- Экранная форма «Должности»

Рисунок 14- Экранная форма «Отделы»

Рисунок 15- Экранная форма «Сотрудники»

Рисунок 16- Экранная форма «УчетРабочегоВремени»

Рисунок 17- Экранная форма расчета заработной платы

Заключение

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

Для выполнения курсового проекта было проведено детальное изучение предметной области, в ходе которой была спроектирована система «ЗП» для автоматизации деятельности бухгалтерии по расчету удержаний за прогулы, начислений по больничным листам, расчету НДФЛ, рассчету конечной заработной платы.

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

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

Система в дальнейшем может быть доработана для ее улучшения.

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

Список использованных источников

1. Калянов Г. Н. CASE-технологии. Консалтинг в автоматизации бизнес-процессов. — 3-е изд. — М.: Горячая линия-Телеком, 2002. — 320 с.

2. Технологии разработки программного обеспечения. Учебное пособие. 2-е изд. / С. Орлов. — СПб.: Питер, 2003. — 480 с.: ил.

3. Шевчук И. С. Проектирование информационных систем: методическое пособие по курсовому проектированию «Проектирование информационных систем». — Пермь, ФГБОУ ВПО Пермская ГСХА, 2013. — 33 с.

4. Шевчук И. С. Проектирование информационных систем: конспект лекций — Пермь: Изд-во ФГБОУ ВПО Пермская ГСХА, 2012. — 59 с.

5. ГОСТ 34. 602−89. Техническое задание на создание автоматизированной системы.