Курсовая работа (т): Автоматизации работы автобусного парка

Автоматизации работы автобусного парка

Введение

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

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

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

Предметом исследования выступает специфика автоматизированной информационной системы учета для расчёта заработной платы. В качестве объекта исследования выступает транспортная компания «АБУС-транс».

При этом отметим, что рассматриваемая нами компания, а именно транспортная компания «АБУС-транс» это многопрофильная компания. К основным направлениям ее деятельности можно отнести следующее:

заказ автобуса и микроавтобуса;

городские грузоперевозки;

квартирные и офисные переезды, услуги грузчиков;

аренда спецтехники;

эвакуация легковых автомобилей.

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

Водитель

Бухгалтер

Депо

Диспетчер

Кондуктор

Цель данного исследования заключается в разработке информационной системы «Расчет зарплаты» для компании «АБУС-транс». Для достижения поставленной нами цели, необходимо решить ряд задач, а именно:

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

рассмотреть модель прецедентов

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

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

рассмотреть модель данных

рассмотреть модель реализации

Структура исследования: наша работа состоит из введения, пяти разделов, заключения, списка использованной литературы и приложения.

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

алгоритм запрос таблица макрос

Перед тем как перейти к системному анализу и анализу требований, отметим, что в качестве объекта исследования являлась транспортная компания «АБУС-транс».

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

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

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

Рисунок 1.1

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

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

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

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

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

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

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

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

Схема, позволяющая определить рамки системы представлена на рисунке 1.2

Рисунок 1.2 - Рисунок системы

Перечень исполнителей и их задач представим в таблице 1.2

Таблица 1.2 Исполнители и их задачи

Также рассмотрим перечень исполнителей и их задач на основе анализа внешних событий. (см. таблицу 1.3)

Таблица 1.3

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

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

Теперь постараемся изобразить диаграмму прецедентов и их описание, на основании нашего исследования. (см. рисунок 1.3)

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

Описание прецедентов

Прецедент П1: Подсчет прибыли.

Основной исполнитель: Бухгалтер.

Заинтересованные лица и их требования:

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

Бухгалтер: Хочет подсчитать полученную прибыль от продажи билетов и распределить ее на оплату налогов и зарплаты.

Предусловия: Бухгалтер должен быть идентифицирован и аутентифицирован.

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

Основной, успешный сценарий:

).В начале рабочего дня бухгалтер фиксирует в «журнале учета»: дату, количество выдающихся билетов, в соответствии с маршрутом; выдает билеты диспетчеру, который передает кондуктору.

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

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

Альтернативный сценарий 1:

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

. Диспетчер передает все бухгалтеру. Бухгалтер заносит всю необходимую информацию в систему.

. Система при подсчете обнаруживает ошибку недостачи, а также количество штрафа.

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

. Бухгалтер заносит в систему уже новые данные. Переход к п. 1).

Прецедент П2: Распределение транспорта по маршрутам.

Основной исполнитель: Диспетчер.

Заинтересованные лица и их требования:

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

Водитель: Хочет иметь в наличии маршрут своего транспорта, путевой лист, расписание остановок, точное время передвижения и остановок.

Предусловия: Диспетчер должен быть идентифицирован и аутентифицирован.

Постусловия: Транспорт распределен по маршрутам.

Основной, успешный сценарий.

).Диспетчер создает путевые листы в системе для всех необходимых маршрутов, в зависимости от количества мест, приходящихся на каждый транспорт, и количеством пассажиров на маршрутах. Все путевые листы хранятся в «журнале П_лист’.

).В начале рабочего дня диспетчер выдает каждому водителю его путевой лист. Диспетчер отправляет транспорт по маршруту. Регистрирует начало каждого маршрута в «журнале регистрации отправки и прибытия транспортов».

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

Альтернативный сценарий 1:

.а) В конце рабочего дня транспорт не возвращается в Депо

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

. При прибытии с маршрута транспорта переход к п. 3).

Альтернативный сценарий 2:

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

. Диспетчер сообщает о повреждениях водителю, в Депо, в систему в «журнал повреждений».

. Транспорт снимают с линии маршрута, заменяя его другим и фиксируя смену в системе.

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

. После ремонта транспорт возвращают на линию маршрута. Переход к п. 3).

Прецедент П3: Расчет с работниками.

Основной исполнитель: Бухгалтер.

Заинтересованные лица и их требования:

Бухгалтер. Хочет точно и быстро выделить средства для оплаты услуг работников.

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

Предусловия: Бухгалтер идентифицирован и аутентифицирован (имеет доступ к определенным ресурсам). Программа загружена.

Постусловия: Расчет с работниками. Занесение и сохранение соответствующей информации в журналах системы.

Основной, успешный сценарий

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

).Система считает прибыль от всех проданных билетов. Бухгалтер отсчитывает некоторую часть прибыли на оплату налогов, заносит в «журнал налогов».

).Система вычисляет заработную плату работникам в соответствии с установленным коэффициентом k, который (от всей суммы прибыли) составляет:

для водителя = 0,3

для кондуктора = 0,15

для диспетчера = 0,15

для бухгалтера =0,2

).Система выводит конечные данные по оплате и сохраняет их. Бухгалтер расплачивается с работниками, фиксируя все расчеты в «журнале ЗП».

Альтернативный сценарий 1:

.а). В систему бухгалтер заносит не всю информацию.

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

. Система выдает сообщение: «НЕДОСТАТОЧНО ДАННЫХ ДЛЯ РАСЧЕТА!!!»

. Бухгалтер вводит уже всю информацию заново. Переход к п. 1.

Прецедент П4: Расчет с поставщиком электроэнергии.

Основной исполнитель: Бухгалтер.

Заинтересованные лица и их требования:

Бухгалтер. Хочет точно и быстро выделить средства для оплаты услуг энергопоставщика.

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