48570 (Разработка информационного обеспечения и анализ данных для информационной системы "Станция технического обслуживания"), страница 2

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

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

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

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

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

Хранение архивов занимает дополнительное помещение, вследствие чего появляются дополнительные денежные затраты. Эта проблема является седьмой.

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

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

Описание автоматизированных бизнес-процессов организации

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

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

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

подсчёт общей стоимости заказа;

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

возможность заходить в базу с разных компьютеров;

автоудаление заказов, не требующих дальнейшего хранения

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

Клиент обращается к секретарю. Секретарь пробивает по существующей базе данного клиента. Если клиент есть в базе данных, то его данные автоматически заполняются в следующем заказе. Если же нет клиента в базе данных организации, то секретарь вводит все данные клиента и оформляет заказ. При этом данные клиента заносятся в базу данных, хранящую информацию о клиентах, и этому клиенту присваивается свой уникальный номер. После заполнения данных о клиенте, выбираются нужные услуги из списка, и информация об услуге автоматически переходит в заказ. Далее происходит автовычисление общей стоимости заказа, и ограничения сроков выполнения согласно требованию клиента. После всего этого заказ сохраняется и становится доступным для менеджера. Секретарь выводит на лист чек, в котором прописан номер заказа, сумма, дата выполнения и данные авто. Менеджер открывает сохранённый заказ, распределяет услуги по мастерам, согласно их нагрузке. Информацию о нагрузке можно просмотреть на сводной форме, в которой прописывается по каждому мастеру все его заказы и сроки их сдачи на текущий момент. Как только заказ снимается с выполнения, эта информация автоматически меняется. После распределения обязанностей менеджер формирует задания на выполнения для каждого мастера и сохраняет как новые задания. При этом формирование задания происходит практически автоматически, считывая информацию с заказа. Бригадир, получив новые задания, распечатывает их на отдельных бланках на выполнение для каждого мастера. Это упрощает работу мастеров, так как им не требуется каждый раз обращаться к рабочей станции системы. После выполнения мастером заказа бригадир принимает работу и отправляет заказ в выполненные. Далее этот заказ лежит в базе до востребования клиентом. Когда клиент приходит за заказом, секретарь проверяет через поиск выполненных заказов есть ли требуемый. Если заказ выполнен, секретарь вызывает по телефону бригадира. Бригадир отводит клиента в сервис и сдаёт ему заказ.

Заказ и поставка деталей и комплектующих осуществляется следующим образом: при переходе заказа в графу "выполненные", все использованные на данный автомобиль детали, переносятся в список "Заказ комплектующих". Также заказать комплектующие может бригадир, вписав её в список заказов. Заказ комплектующих непосредственно поставщикам и контроль поставок осуществляет товаровед.

1.3 Постановка задачи на проектирование

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

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

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

подсчёт общей стоимости заказа;

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

возможность заходить в базу с разных компьютеров;

автоудаление заказов, не требующих дальнейшего хранения

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

В АИС должны храниться следующие данные:

база клиентов;

база мастеров;

база комплектующих;

база выполненных заказов

текущие данные о заказах, зарплатах, комплектующих

Доступ к базе данных у всех сотрудников одинаков.

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

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

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

большая бумажная волокита;

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

затруднение поиска нужного;

хранение много лишней макулатуры.

Также описаны автоматизированные бизнес-процессы и их преимущества:

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

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

подсчёт общей стоимости заказа;

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

возможность заходить в базу с разных компьютеров;

автоудаление заказов, не требующих дальнейшего хранения

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

2. Проектирование информационного обеспечения и функциональной части АИС

2.1 Проектирование внешнего информационного обеспечения

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

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

Одни и те же услуги могут выполнять разные мастера, поэтому услугу можно представить как отдельный объект. С другой стороны один и тот же мастер может выполнять много услуг, поэтому отношение между услугой и мастером будет многие-ко-многим.

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

Для формирования финансового отчёта необходимо учитывать заработную плату всех сотрудников, которая определяется окладом, заработную плату мастеров, которая начисляется в соответствии с выполненными заказами, а также расходы на покупку деталей. То есть появляется ещё один объект "отчёт", который включает в себя информацию о заработных платах и о заказах склада. Отношение между сотрудником и отчётом - один-ко-многим, так как в отчёте хранятся данные о всех сотрудниках, а у одного сотрудника может быть только одна зарплата. Аналогично определяется связь между зарплатой мастера и отчётом. Связь между заказом деталей и отчётом так же будет один-ко-могим, так как в отчёте хранятся данные по четырём заказам склада, соответствуя четырём неделям месяца. Заказ склада, в свою очередь содержит в себе информацию о деталях и стоимость. Связь между деталью и заказом склада - один-ко-многим.

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

2.2 Инфологическое проектирование данных

Согласно представленным объектам в системном анализе предметной области необходимо представить объекты в виде сущностей и связей. Для этого будет использоваться методология Питера Чена:

Рисунок 3 - Инфологическая модель данных

В данной схеме хорошо просматриваются сущности, их атрибуты и связи. Сущности и связи соответствуют объектам, выделенным в предыдущем пункте, и их связям.

Датaлогическое проектирование. Нормализация данных

Для дальнейшего проектирования необходимо выбрать CASE-средства. Оценка CASE-средств будет производиться по следующим критериям:

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

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

простота освоения. Трудовые и временные затраты на освоение средств;

совместимость обновлений (совместимость новых версий с существующими, включая, например, совместимость по входным или выходным данным);

совместимость с версиями ОС (возможность работы в среде различных версий одной и той же ОС, простота модификации CASE-средства для работы с новыми версиями ОС);

переносимость данных между различными версиями CASE-средства;

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

Каждый критерий может иметь оценку 0-5.

Оценка "0" означает, что данное программное обеспечение полностью не удовлетворяет требованию критерия.

Оценка "5" означает, что данный критерий выполняется полностью.

То CASE-средство, которое будет иметь наибольший балл, будет принято. Балл этого программного обеспечения не должен быть меньше 30.

Оценка отражена в таблице1.

В выборе и оценке учавствуют следующие программные средства: Vantage Team Builder (Westmount I-CASE), Designer/2000, Silverrun, ERwin+BPwin, S-Designor, CASE. Аналитик.

Таблица 1

Оценка CASE-средств

Из приведённой таблицы видно, что наиболее удобным средством для проектирования является Computer Associates Erwin, так как он имеет наибольший балл.

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

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

Рисунок 4 - Модель данных до нормализации

Рисунок 5 - Логическая схема данных

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

Физическое проектирование без учёта ПО для разработки СУБД

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