logo
Разработка автоматизированной информационной системы учета для расчёта заработной платы ОАО РПТ "Авторемонтник"

Выводы к разделу

ЗАКЛЮЧЕНИЕ

СПИСОК СОКРАЩЕНИЙ

CПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ

ПРИЛОЖЕНИЕ А - СПЕЦИФИКАЦИЯ ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

ПРИЛОЖЕНИЕ Б - ТЕХНИЧЕСКОЕ ЗАДАНИЕ

ПРИЛОЖЕНИЕ В - ТЕСТОВЫЕ ПРИМЕРЫ

ПРИЛОЖЕНИЕ Г -- ОБОСНОВАНИЕ МОДЕЛИ ВЫБОРА ЖИЗНЕННОГО ЦИКЛА

ПРИЛОЖЕНИЕ Д - ДИАГРАММА ГАНТА

ПРИЛОЖЕНИЕ Е - РЕЗУЛЬТАТЫ ЭКСПЕРНОГО ОПРОСА

информационная система модуль база данных

ВВЕДЕНИЕ

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

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

На современном этапе развития информатизации и автоматизации характерно использование распределенной обработки информации. Наиболее перспективной сферой использования концепции распределенной обработки информации является автоматизация планово-управленческих функций на базе персональных компьютеров, установленных непосредственно на рабочих местах специалистов. Системы, выполняющие эти функции, получили широкое распространение под названием автоматизированные рабочие места (АРМ) [1].

Цель данной работы является разработка информационной системы «Расчёт зарплаты» для предприятия ОАО РТП «Авторемонтник». Для достижения данной цели необходимо решить следующие задачи:

– сбор, анализ, аттестация требований;

– разработка объектной модели системы;

– реализация и тестирование системы;

– развертывание системы;

– экспертная оценка системы.

1. РАЗРАБОТКА ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

1.1 Анализ существующих решений по автоматизации предметной области

На данный момент на рынке существуют множество средств для расчёта заработной платы на предприятии. Наиболее популярные из них являются «1С: Предприятие» и «БухСофт: Предприятие».

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

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

Рисунок 1.1 - Пример работы «1С:Предприяие».

Достоинствами «1С: Предприятие» является:

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

- обладает высокой производительностью, что дает возможность решать с ее помощью самые сложные задачи;

- возможность использовать MS SQL Server.

Недостатки:

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

- затруднен поиск ошибок, сделанных во время обработки документов;

- программа является платной;

- из-за уникальности предприятий конфигурации требуют доработки.

Программа «БухСофт: Предприятие» предназначена для комплексной автоматизации бухгалтерского, налогового, управленческого, кадрового, складского и оперативного учета на предприятии в полном соответствии с требованиями бухгалтерского, налогового и трудового законодательства [3]. Пример работы программы показан на рисунке 1.2.

Рисунок 1.2 - Пример работы программы «БухСофт: Предприятие».

Достоинства программы:

- формирование отчётов в Microsoft Exel;

- высокая производительность.

Недостатки программы:

- программа является платной;

- в программе не предусмотрено взаимодействие с удалённым сервером базы данных.

Рассматривая аналогичные прикладные решения можно сделать вывод, что они не удовлетворяют требованиям поставленной задачи. В связи с этим принято решение разработать программу «Расчёт зарплаты» в рамках данного дипломного проекта, которая позволит вести учет заработной платы сотрудникам предприятия ОАО РТП «Авторемонтник».

1.2 Выбор методологии проектирования информационной системы

Среди множества методологий проектирования информационной системы наибольшую популярность приобрели компонентно-ориентированное и объектно-ориентированное программирование.

Основополагающей идеей ООП является объединение данных и обрабатывающих их процедур в единое целое -- объект.

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

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

ООП дает возможность создавать расширяемые системы (extensible systems). Это одно из самых значительных достоинств ООП и именно оно отличает данный подход от традиционных методов программирования. Расширяемость (extensibility) означает, что существующую систему можно заставить работать с новыми компонентами, причем без внесения в нее каких-либо изменений. Компоненты могут быть добавлены на этапе выполнения [5].

Компонентно-ориентированное программирование -- это своеобразная «надстройка» над ООП, набор правил и ограничений, направленных на построение крупных развивающихся программных систем с большим временем жизни. Программная система в этой методологии представляет собой набор компонентов с хорошо определёнными интерфейсами. Изменения в существующую систему вносятся путём создания новых компонентов в дополнение или в качестве замены ранее существующих. При создании новых компонентов на основе ранее созданных запрещено использование наследования реализации - новый компонент может наследовать лишь интерфейсы базового. Таким образом, компонентное программирование обходит проблему хрупкости базового класса [6, 7].

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

– возможность повторного использования кода;

– отсутствие необходимости разработки классов с нуля, за счет наследования;

– повышение безопасности кода за счет инкапсуляции;

– гибкость при модификации и расширении системы;

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

1.3 Анализ предметной области

Строительство ОАО РТП «Авторемонтник» началось в мае 1964 года на бывшем пустыре в юго-восточной части города Сальска рядом с Сальской текстильно-галантерейной фабрикой. Проектно-сметная документация была разработана в 1963 году Ростовским отделением института «Гипроавтотранс». Проектная мощность авторемонтного завода составила 1600 условных ремонтов автомобилей ГАЗ-51 в год (1000 шт. автомобилей, 1000 шт. двигателей, 1000 шт. КПП, и по 1000шт. задних и передних мостов).

Направление деятельности предприятия:

– производит установку на автобусы марки ЛАЗ, ЛИАЗ, «Икарус», автомобиль марки КАМАЗ и другую технику двигатели марки ЯМЗ-236, ЯМЗ-238, на автомобиль марки УАЗ-469 утепленную металлическую крышу и дизельный двигатель марки Д-21;

– производит ремонт автобусов марки ЛАЗ, ЛИАЗ, КАВЗ, ПАЗ, «Кубань», и реализация прошедших капитальный ремонт автобусов марки «Кубань»;

– производит установку ремней безопасности на пассажирские автобусы;

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

– производит продажу тепловой энергии физическим и юридическим лицам. Организационная структура предприятия изображена на рисунке 1.3.

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

Рисунок 1.3 - Организационная структура предприятия.

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

На предприятии используется повременная системы оплаты труда.

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

1. обязательные удержания, на которые не требуется соглашение работника;

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

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

Трудовые доходы, т.е. все виды оплаты труда, облагаются по единой ставке 13 %.

Пассивные доходы облагаются по более высоким фиксированным ставкам:

– 30 % - суммы дивидендов, доходы, полученные лицами, не являющимися налоговыми резидентами Российской Федерации;

– 35 % - доходы в виде выигрышей по лотереям, тотализаторам и другим играм, основанным на риске; стоимость призов и выигрышей, полученных на конкурсах и др.;

– 9 % - доходы в виде дивидендов, получаемых физическими лицами, являющимися резидентами.

1.4 Сбор требований

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

Требования - это описание необходимых или желаемых свойств продукта.

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

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

Сбор требований проводился методом интервьюирования, который заключается в беседе между разработчиком системы и заказчиком. Этот метод применяется, когда большим объемом знаний обладает ограниченный круг людей, и обычно используется для беседы с одним человеком [9, 10].

В таблице 1.1 приведены вопросы и ответы из интервью с бухгалтером.

Таблица 1.1 - Сбор требований способом «интервью»

Вопрос

Ответ

Для чего проектируется информационная система?

Целью информационной системы является расчёт заработной платы сотрудникам ОАО РТП «Авторемонтник».

Какая система оплаты труда используется на предприятии?

Повременная система оплаты труда

Чем занимается администратор ИС?

Администратор системы подготавливает ПК к установке, настройке и последующей эксплуатации информационной системы.

Какую роль играет работник отдела кадров в ИС?

Заполняет лицевые счета работников и ведёт их личные дела.

На какой операционной системе будет запускаться ИС?

Windows XP.

Какую форму отчёта должна выгружать информационная система?

Расчетный листок.

Таблица 1.1 - Сбор требований способом «интервью» продолжение

Какой вид интерфейса более предпочтителен?

Приложение должно иметь визуальное оформление с поддержкой оконного режима.

Какие дополнительные возможности должны будут реализованы в ИС?

- Возможность одновременного заполнения данных с двух разных компьютеров находящихся в одной сети с последующей синхронизацией;

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

- Возможность сохранения данных и просмотр данных за предыдущие периоды.

1.5 Анализ и моделирование требований

Цель анализа -- качественно и подробно описать требования, которые позволят менеджерам реалистично оценить все затраты на проект, а разработчику -- начать проектирование, разработку и тестирование [11].

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

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

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

Рисунок 1.4- Диаграмма вариантов использования

В информационной системе используются три роли:

– администратор ИС;

– работник отдела кадров;

– бухгалтер.

Таблица 1.2- Описание ролей информационной системы

Название роли

Описание

Администратор ИС

Создаёт и удаляет пользователей, следит за работой информационной системы. Устраняет неисправности в работе системы.

Сотрудник отдела кадров

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

Бухгалтер

Производит расчёт заработной платы.

Выводит отчёты.

Диаграмма классов -- статическая структурная диаграмма, описывающая структуру системы, демонстрирующая классы системы, их атрибуты, методы и зависимости между классами [8]. Диаграмма классов предоставлена на рисунке 1.5.

Рисунок 1.5- Диаграмма классов

Таблица 1.3-Описание классов

Имя класса

Назначение класса

Клиент

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

Администратор

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

Сотрудник отдела кадров

Унаследован от класса Клиент. Добавляет и редактирует данные о сотрудниках предприятия

Бухгалтер

Унаследован от класса Клиент. Позволяет производить расчёт заработной платы сотрудникам предприятия.

Пользователь

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

Сотрудник

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

Отдел

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

1.6 Спецификация требований

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

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

Таблица 1.4 - Категории описания требований

Категория

Описание

F

Функциональные требования, описывающие требуемую функциональность или прецеденты системы

S

Системные требования, такие как используемые платформы

P

Требования к представлению

R

Требования, определяющие риски, которым должно быть уделено основное внимание при разработке системы

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

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

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

Требование

Тип

Описание

Аутентификация пользователя

F

Для работы в системе необходимо пройти аутентификацию

Непротиворечивый ввод данных

F

Проверка типов данных на стадии ввода

Отчеты по требованию

F

Отчеты, которые запрашивают вышестоящие органы

Второй категорией в описании требований является категория системных требований - S. Описания системных требований представлены в таблице 1.3.

Таблица 1.6 - Системные требования

Требование

Тип

Описание.

Архитектура

S

Pentium IV 1GHz CPU

Платформа

S

Windows XP

СУБД

S

MySQL 5.1.40

Язык программирования

S

.NET Framework

C#

Информационно-логический язык

S

Язык структурированных запросов SQL

Transact-SQL расширение языка SQL

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

Таблица 1.7 - Требования к представлению

Требование

Тип

Описание.

Интерфейс рабочего окна

P

Простая и строгая, не раздражающая глаза цветовая гамма

Корректный ввод данных

P

Данные несоответствующих типов не принимаются, выдается предупреждение

Простота интерфейса

P

Интуитивно понятный интерфейс

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

Таблица 1.8 - Требования к рискам

Требование

Тип

Описание

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

R

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

Построение отчетов

R

Полное соответствие содержимому в таблицах

Сохранность и целостность данных

R

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

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

Спецификация требований (Software Requirements Specification, SRS) используется для текущего сопровождения проекта и представления требований, сформулированных по отношению к проекту. SRS позволяет определить предметную область программного продукта, рассматриваемого относительно трех его основных составляющих: данных, процесса и поведения. Спецификация SRS позволяет от определения предметной области проекта перейти к области решений, определив три модели требований, отображающие характеристики данных, процесса и поведения [11, 12]. Данный документ должен содержать состав и наименование комплексов задач, требования по изменению организационной структуры, состав обеспечивающих подсистем [13]. Спецификация требований к программному обеспечению представлена в Приложении A.

1.7 Аттестация требований

Данный раздел включает в себя формирование «Технического задания».

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

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

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

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

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

Целью разработки ТЗ проекта АИС является оценка основных параметров, ограничивающих проект информационной системы, обоснование выбора и оценка основных проектных решений по отдельным компонентам проекта.

Подробно техническое задание описано в Приложение Б.

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

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

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

– прояснение и завершение процесса формулировки требований;

– исследование альтернативных решений;

– создание конечного продукта.

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

Сложность современных GUI-интерфейсов делают прототипирование обязательным элементом разработки ПО. Прототипы позволяют оценить реализуемость и полезность разрабатываемой системы до начала ее реализации [14].

Иерархия окон приложения для клиента Администратор показана на рисунке 1.6.

Рисунок 1.6-Иерархия окон приложения для клиента администратора.

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

Иерархия окон приложения для клиента сотрудника отдела кадров показана на рисунке 1.7.

Рисунок 1.7- Иерархия окон приложения для клиента сотрудника. отдела кадров

Иерархия окон приложения для клиента бухгалтера показана на рисунке 1.8.

Рисунок 1.8 - Иерархия окон приложения для клиента бухгалтера.

Прототип диалогового окна показан на рисунке 1.9.

Рисунок 1.9 - Прототип диалогового окна.

Прототип главного окна показан на рисунке 1.10.

Рисунок 1.10 - Прототип главного окна.