Разработка интерфейсной и функциональной части информационной системы для станции технического обслуживания. Анализ предметной области и постановка задачи на проектирование. Математические методы в прогнозировании. Реализация модуля прогнозирования.
Анализ предметной области, постановка задачи на проектирование, Инфологическое проектирование даны, Даталогическое проектирование. Нормализация данных, Физическое проектирование, Функциональная схема приложения, Математические методы в прогнозировании, Отладка и тестирования, методология Чена
Основной целью курсовой работы является разработка интерфейсной и функциональной части информационной системы для станции технического обслуживания.
Для достижения данной цели выполнен ряд задач: проанализирована предметная область, выявлены основные виды деятельности организации, рассмотрена структура организации, определен уровень автоматизации на текущий момент, выявлены проблемы, которые необходимо устранить с помощью автоматизации, разработана схема автоматизированной работы организации, разработан проект информационной системы, выбрано программное обеспечение для реализации.
Предметом исследования является автоматизация информационной системы с учетом всех требований к применяемому для разработки программному обеспечению.
Объектом исследования является станция технического обслуживания, систему которой необходимо автоматизировать для упрощения и удобства работы сотрудников.
Результат данного проекта - информационная система с удобным интерфейсом и работоспособной функциональной частью.
Содержание
Введение
1. Анализ предметной области и постановка задачи на проектирование
1.1 Описание деятельности организации
1.2 Определение проблемных областей в функционировании организации
1.3 Постановка задачи на проектирование
2. Проектирование информационного обеспечения и функциональной части АИС
2.1 Проектирование внешнего информационного обеспечения
2.2 Инфологическое проектирование данных
2.3 Анализ и выбор ПО для разработки СУБД
2.4 Функциональная схема приложения
2.5 Описание особенностей интерфейса. Разработка отчетов
2.6 Математические методы в прогнозировании
2.6.1 Формулировка задачи на прогнозирование
2.6.2 Экстрополяционные методы прогнозирования
2.6.3 Метод Исторической Аналогии
2.6.4 Экспертные методы
2.6.5 Метод эвристического прогнозирования (МЭП)
2.6.6 Балансовый метод
2.6.7 Сбор данных. Описание исходных данных
2.7 Выходные данные, графики, прогнозы
3. Реализация БД и функциональной части АИС
3.1 Реализация БД в среде С Builder
3.2 Разработка интерфейса приложения
3.3 Описание реализации модуля прогнозирования
3.4 Тестирование нефункциональных параметров программы
Заключение
Литература
Введение
Актуальность. На любых предприятиях, станциях, заводах существуют базы данных, содержащие информацию о всех необходимых объектах, а также о работающем персонале. Для того, чтобы вести отчетность или изменять какие-либо данные в этих базах, необходимо заполнять множество бумажных документов, что очень затрудняет работу сотрудников и требует дополнительные затраты на работников таких отделов. Поиск нужной информации также затруднен, так как в большом количестве информации очень сложно искать нужные данные вручную. Из представленных проблем очевидно, что необходимо создать систему сбора, хранения и обработки данных, которая упростит работу сотрудников. Информационная система позволит перейти на более высокий уровень обслуживания клиентов, заполнения договоров и ведения отчетности.
Цель курсового проекта: Разработать интерфейсную и функциональные части информационной системы для станции технического обслуживания.
Задачи: проанализировать предметную область;
выявить основные виды деятельности организации;
рассмотреть структуру организации;
определить уровень автоматизации на текущий момент;
выявить проблемы при работе, которые необходимо устранить с помощью автоматизации;
разработать схему автоматизированной работы организации разработать проект информационной системы, учитывая все этапы проектирования;
выбрать программное обеспечение для реализации;
реализовать проект, учитывая все требования к интерфейсной и функциональной частям.
Предмет исследования: автоматизация информационной системы с учетом всех требований к применяемому для разработки программному обеспечению.
Объект исследования: станция технического обслуживания, систему которой необходимо автоматизировать для упрощения и удобства работы сотрудников.
1. Анализ предметной области и постановка задачи на проектирование
1.1 Описание деятельности организации
В настоящий момент в организации работают: секретарь, менеджер, бригадир, мастера по различным услугам, товаровед.
Товаровед ведет учетность деталей и других товаров и комплектующих, которые можно приобрести или заменить на СТО. В его обязанности входит: Выявления нехватающих комплектующих;
Заказ комплектующих;
Контроль поставок комплектующих;
Ведение отчетности по комплектующим
Секретарь работает с клиентами. В его обязанности входит: Оформление заказа;
Проставление стоимости услуг;
Подсчет стоимости заказа;
Прием оплаты;
Выписка чека;
Снятие заказа с учета после его выдачи заказчику
Отправка заказа в архив
Менеджер распределяет работы и ведет финансовую отчетность. В его обязанности входит: Распределение заказов по мастерам;
Оформление бланка на выполнение;
Снятие заказа с учета на выполнение (после его выполнения);
Начисление заработной платы;
Ведение финансовой отчетности
Бригадир курирует работу мастеров, принимает работу и сдает ей заказчику. В его обязанности входит: Прием от менеджера бланков на выполнение;
Доставка бланков до мастеров;
Контроль сроков выполнения заказов;
Прием работы мастеров;
Информирование менеджера о завершении работ;
Сдача выполненного заказа клиенту
Каждый мастер принимает заказ на выполнение, подписывает бланк на выполнение, выполняет заказ и сдает.
Описание бизнес-процессов организации на текущий момент
Клиент приходит на станцию технического обслуживания и обращается к секретарю. Секретарь на специальном бланке оформляет заказ, проставляет в нем стоимости всех услуг согласно ценам, поставленным данной организацией, которые прописаны в постановлении о стоимости услуг. Далее секретарь подсчитывает стоимость всего заказа, принимает оплату от клиента и выписывает чек. В чеке прописываются данные заказчика, данные его автомобиля, номер заказа, стоимость. В конце дня секретарь сдает все эти бланки менеджеру. На следующий день менеджер ознакамливается с оформленными заказами и распределяет их по мастерам, учитывая загруженность того или иного мастера, прописывая его данные на бланке заказа. Далее менеджер оформляет бланк на выполнение, в котором прописывает номер заказа, данные мастера, услуги, требования и сроки выполнения. Бланки на выполнение сдаются бригадиру, который доставляет их мастерам. Мастер принимает заказ на выполнение, ознакамливается с требованиями и подписывает бланк на выполнение. После выполнения заказа мастер оповещает об этом бригадира. Бригадир принимает работу и, если нет замечаний, отмечает на бланке на выполнение завершение заказа, информирует менеджера о выполнении заказа и сдает бланк. Менеджер отмечает в бланке заказа выполнение, в книге "Отчеты заработной платы" прописывает сумму от выполненного заказа мастеру, отдает бланк выполненного заказа секретарю. Когда клиент приходит за своим заказом, секретарь по чеку заказчика ищет бланк выполненного заказа. Если такой имеется, то клиента направляют к бригадиру с бланком заказа. Бригадир сдает работу клиенту. Если клиент не имеет претензий, он забирает свой автомобиль и ставит на бланке заказа в графе замечания "нет замечаний". После этого бригадир возвращает бланк секретарю, секретарь закрепляет степлером бланк заказа, чек заказчика и бланк на выполнение и складывает в архив. Если же клиент не удовлетворен работой, то заказ ставится на учет "Доработка" и возвращается мастеру. После выполнения доработки заказ проходит тот же путь, что и после первого выполнения.
Для лучшего понимания все эти процессы можно отобразить схемой:
Рисунок 1 - Краткая схема бизнес-процессов на СТО
Рисунок 2 - схема продвижения документов на выполнение заказа
Работу товароведа можно описать следующим образом: каждую неделю товаровед берет выполненные заказы у секретаря, смотрит какие комплектующие были использованы, ищет в книге "Заказ комплектующих" название этой детали и добавляет одну единицу в заказ данной детали. Далее подсчитывает количество каждой детали, которую надо приобрести, подсчитывает сумму заказа и заказывает детали у поставщика. Деньги на заказ комплектующих перечисляются еженедельно в одном и том же размере.
1.2 Определение проблемных областей в функционировании организации
Рассмотрев подетально каждый процесс на станции технического обслуживания, можно выявить ряд проблем, связанных с ручным заполнением различных документов.
Во-первых, когда приходит клиент для оформления заказа, необходимо заново заполнять все его данные, даже если он обращается в данную организацию не первый раз.
Во-вторых, ручное заполнение документов подвергает риску ошибок.
В-третьих, присутствует слишком много бумажной волокиты, связанной с тем, что один и тот же заказ обрабатывают разные люди.
В-четвертых, возможна утеря одной или нескольких составляющих документации о заказах.
В-пятых, хранение архивов заказов в бумажных библиотеках значительно затрудняет поиск нужного заказа при возникновении какой-либо спорной или конфликтной ситуации.
В-шестых, хранение архивов заказов необходимо в течении трех лет, после чего их следует уничтожить. Для человека становится накладно проверять даты заказов и удалять просроченные, поэтому часто хранится много лишней макулатуры.
Хранение архивов занимает дополнительное помещение, вследствие чего появляются дополнительные денежные затраты. Эта проблема является седьмой.
Восьмой причиной внедрения автоматизации является неудобная и неэффективная работа с заказами комплектующих и введения отчетности в данной области. Ручное оформление заказа и ведение отчетности замедляет и усложняет работу товароведа. Также имеется большой риск ошибок изза частой переписи названий и параметров комплектующих.
Таким образом, проблемной областью считается ведение бумажной документации и полное отсутствие автоматизации.
Описание автоматизированных бизнес-процессов организации
Для решения перечисленных выше проблем, необходимо разработать автоматизированную информационную систему, которая будет позвалять выполнять поиск, что ускорит заполнение заказа и выполнять автоматически следующие некоторые процессы. А именно: возможность найти клиента из базы, если этот клиент однажды обращался в данную организацию;
поиск и выбор нужных услуг с возможностью автозаполнения информации по ней;
подсчет общей стоимости заказа;
перечисление денежных средств на зарплатный накопитель мастера, выполняющему оплаченную услугу;
возможность заходить в базу с разных компьютеров;
автоудаление заказов, не требующих дальнейшего хранения
Таким образом, бизнес-процессы в организации после реализации автоматизации можно описать следующим образом: Клиент обращается к секретарю. Секретарь пробивает по существующей базе данного клиента. Если клиент есть в базе данных, то его данные автоматически заполняются в следующем заказе. Если же нет клиента в базе данных организации, то секретарь вводит все данные клиента и оформляет заказ. При этом данные клиента заносятся в базу данных, хранящую информацию о клиентах, и этому клиенту присваивается свой уникальный номер. После заполнения данных о клиенте, выбираются нужные услуги из списка, и информация об услуге автоматически переходит в заказ. Далее происходит автовычисление общей стоимости заказа, и ограничения сроков выполнения согласно требованию клиента. После всего этого заказ сохраняется и становится доступным для менеджера. Секретарь выводит на лист чек, в котором прописан номер заказа, сумма, дата выполнения и данные авто. Менеджер открывает сохраненный заказ, распределяет услуги по мастерам, согласно их нагрузке. Информацию о нагрузке можно просмотреть на сводной форме, в которой прописывается по каждому мастеру все его заказы и сроки их сдачи на текущий момент. Как только заказ снимается с выполнения, эта информация автоматически меняется. После распределения обязанностей менеджер формирует задания на выполнения для каждого мастера и сохраняет как новые задания. При этом формирование задания происходит практически автоматически, считывая информацию с заказа. Бригадир, получив новые задания, распечатывает их на отдельных бланках на выполнение для каждого мастера. Это упрощает работу мастеров, так как им не требуется каждый раз обращаться к рабочей станции системы. После выполнения мастером заказа бригадир принимает работу и отправляет заказ в выполненные. Далее этот заказ лежит в базе до востребования клиентом. Когда клиент приходит за заказом, секретарь проверяет через поиск выполненных заказов есть ли требуемый. Если заказ выполнен, секретарь вызывает по телефону бригадира. Бригадир отводит клиента в сервис и сдает ему заказ.
Заказ и поставка деталей и комплектующих осуществляется следующим образом: при переходе заказа в графу "выполненные", все использованные на данный автомобиль детали, переносятся в список "Заказ комплектующих". Также заказать комплектующие может бригадир, вписав ее в список заказов. Заказ комплектующих непосредственно поставщикам и контроль поставок осуществляет товаровед.
1.3 Постановка задачи на проектирование
На основе описания автоматизированных бизнес-процессов станции технического обслуживания поставлена задача: разработать автоматизированную информационную систему для СТО, в которой автоматически будут осуществляться следующие функции: поиск клиента, который однажды обращался в данную организацию;
поиск и выбор нужных услуг с возможностью автозаполнения информации по ней;
подсчет общей стоимости заказа;
перечисление денежных средств на зарплатный накопитель мастера, выполняющему оплаченную услугу;
возможность заходить в базу с разных компьютеров;
автоудаление заказов, не требующих дальнейшего хранения составление списка комплектующих, которые необходимо поставить
В АИС должны храниться следующие данные: база клиентов;
база мастеров;
база комплектующих;
база выполненных заказов текущие данные о заказах, зарплатах, комплектующих
Доступ к базе данных у всех сотрудников одинаков.
Таким образом, в данном разделе была рассмотрена структура организации и деятельность всех сотрудников. Были описаны все бизнес-процессы на текущий момент и определены проблемные области: необходимость заполнения заново всех данных клиента, даже если он обращается в данную организацию не первый раз;
ручное заполнение документов подвергает риску ошибок;
большая бумажная волокита;
возможность утери одной или нескольких составляющих документации о заказах;
затруднение поиска нужного;
хранение много лишней макулатуры.
Также описаны автоматизированные бизнес-процессы и их преимущества: возможность найти клиента из базы, если этот клиент однажды обращался в данную организацию;
поиск и выбор нужных услуг с возможностью автозаполнения информации по ней;
подсчет общей стоимости заказа;
перечисление денежных средств на зарплатный накопитель мастера, выполняющему оплаченную услугу;
возможность заходить в базу с разных компьютеров;
автоудаление заказов, не требующих дальнейшего хранения
Произведена постановка задачи на проектирование: разработать автоматизированную информационную систему для СТО, в которой автоматически будут осуществляться функции, описанные в автоматизированных бизнес-процессах.
2. Проектирование информационного обеспечения и функциональной части АИС
2.1 Проектирование внешнего информационного обеспечения
Согласно обязанностям сотрудников, описанных в системном анализе можно более точно описать их деятельность, чтобы составить выделить объекты и определить связи между ними.
Секретарь оформляет заказ. Менеджер принимает заказ на выполнение, формирует задание для мастеров и передает бригадиру. Бригадир принимает на выполнение, принимает выполненный заказ и снимает его с выполнения. Таким образом заказ содержит информацию о клиенте, обо всех сотрудниках, принимавших участие в организации заказа, о всех мастерах, выполнявших заказ, и об услугах, которые они выполняют о деталях, использовавших в заказе. Связь между клиентом и заказом будет один-ко-многим, так как в заказе может быть только один клиент, а у одного клиента может быть несколько заказав, причем даже сделанных в разное время. Связь между сотрудниками и заказом - многие-ко-многим, так как в организации заказов принимают участие несколько сотрудников, но также каждый из сотрудников организовывает много заказов. Аналогично, определяются связь между заказом и мастером. Связь между заказом и деталью тоже будет многие-ко-многим, так как в одном заказе могут быть несколько деталей, также детали, имеющие одни и те же параметры могут быть использованы, в разных заказах.
Одни и те же услуги могут выполнять разные мастера, поэтому услугу можно представить как отдельный объект. С другой стороны один и тот же мастер может выполнять много услуг, поэтому отношение между услугой и мастером будет многие-ко-многим.
Зарплата мастеров зависит от выполняемых заказов, поэтому для каждого мастера необходимо завести "зарплатную книжку", то есть сформировать таблицу, которая будет в себе содержать информацию о мастере и его текущие начисления. То есть появляется новый объект "зарплата мастера".
Для формирования финансового отчета необходимо учитывать заработную плату всех сотрудников, которая определяется окладом, заработную плату мастеров, которая начисляется в соответствии с выполненными заказами, а также расходы на покупку деталей. То есть появляется еще один объект "отчет", который включает в себя информацию о заработных платах и о заказах склада. Отношение между сотрудником и отчетом - один-ко-многим, так как в отчете хранятся данные о всех сотрудниках, а у одного сотрудника может быть только одна зарплата. Аналогично определяется связь между зарплатой мастера и отчетом. Связь между заказом деталей и отчетом так же будет один-ко-могим, так как в отчете хранятся данные по четырем заказам склада, соответствуя четырем неделям месяца. Заказ склада, в свою очередь содержит в себе информацию о деталях и стоимость. Связь между деталью и заказом склада - один-ко-многим.
Таким образом выделены следующие объекты: заказ, клиент, сотрудник, принимающий участие в организации заказа (секретарь, менеджер, бригадир), мастер, услуга, квалификация, заработная плата мастера, деталь, заказ деталей, отчет по распределению финансов.
2.2 Инфологическое проектирование данных
Согласно представленным объектам в системном анализе предметной области необходимо представить объекты в виде сущностей и связей. Для этого будет использоваться методология Питера Чена:
Рисунок 3 - Инфологическая модель данных
В данной схеме хорошо просматриваются сущности, их атрибуты и связи. Сущности и связи соответствуют объектам, выделенным в предыдущем пункте, и их связям.
Даталогическое проектирование. Нормализация данных
Для дальнейшего проектирования необходимо выбрать 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-средств
CASE-средства Критерии оценки Westmount I-CASE Designer/2000 Silverrun ERWIN BPWIN S-Designor CASE. Аналитик возможность ввода и редактирования информации, описывающей элементы данных системы и их отношения 5 5 5 5 5 5 удобство пользовательского интерфейса 4 3 3 5 4 4 простота освоения 4 3 4 5 5 4 совместимость обновлений 5 5 5 5 5 4 совместимость с версиями ОС 5 5 5 5 4 5 переносимость данных между различными версиями CASE-средства 5 4 5 5 4 5 затраты на CASE-средство 4 3 0 4 4 0
ИТОГОВЫЙ БАЛЛ 32 28 27 34 31 26
Из приведенной таблицы видно, что наиболее удобным средством для проектирования является Computer Associates Erwin, так как он имеет наибольший балл.
Переведем сущности и связи, определенные в предыдущем пункте, в отношения и связи. Для этого будем использовать логическую ER-модель.
Для нормализации данных необходимо устранить связи многие-ко-многим. Для этого эти связи разрываются дополнительной таблицей. Эта нормализация отображена на рисунке 5.
Рисунок 4 - Модель данных до нормализации
Рисунок 5 - Логическая схема данных
Нормализация необходима для устранения избыточности данных, которая возможна при наличии связей многие-ко-многим.
Физическое проектирование без учета ПО для разработки СУБД
Все СУБД имеют определенный набор типов данных, имеющих одинаковый смысл, но имеющие разное написание. Поэтому можно определить общие типы данных, не ссылаясь на определенную СУБД. Для этого для каждой таблицы опишем все атрибуты, их расшифровки и общие типы.
Таблица 2
Определение типов таблицы "Клиент"
Атрибут Расшифровка Тип id_klient Идентификационный номер Автосчетчик fam Фамилия Строка name Имя Строка otch Отчество Строка nomer_avto Номер автомобиля Строка
Таблица 3
Определение типов таблицы "Заказ"
Атрибут Расшифровка Тип id_sakas Идентификационный номер Автосчетчик id_klient ID клиента Длинное целое data_oformlenia Дата оформления Дата stoimost Стоимость Деньги data_vipolnenia Дата выполнения Дата data_zakritia Дата закрытия Дата
Таблица 4
Определение типов таблицы "Деталь"
Атрибут Расшифровка Тип id_detal Идентификационный номер Автосчетчик
Detal Деталь Строка
Cena Цена Деньги kol Количество Байт
Таблица 5
Определение типов таблицы "Заказ склада"
АТРИБУТРАСШИФРОВКАТИП id_sak_sklada Идентификационный номер Автосчетчик id_detal ID детали Длинное целое
Stoim_sak Стоимость заказа Деньги
Таблица 6
Определение типов таблицы "Деталь-заказ"
Атрибут Расшифровка Тип id_detal ID детали Длинное целое id_sakas ID заказа Длинное целое id_klient ID клиента Длинное целое
Таблица 7
Определение типов таблицы "Мастер"
Атрибут Расшифровка Тип id_master Идентификационный номер Автосчетчик
Fam Фамилия Строка
Name Имя Строка
Otch Отчество Строка
Stash Стаж Байт nomer_pasp Номер паспорта Длинное целое seria_pasp Серия паспорта Целое data_post_na_rab Дата поступления на работу Дата id_kvalif ID квалификации Длинное целое
Таблица 8
Определение типов таблицы "Квалификация"
АТРИБУТРАСШИФРОВКАТИП id_kvalif Идентификационный номер Автосчетчик
Kvalif Квалификация Строка
Таблица 9
Определение общих типов таблицы "Мастер-заказ"
АТРИБУТРАСШИФРОВКАТИП id_master ID мастера Длинное целое id_sakas ID заказа Длинное целое id_klient ID клиента Длинное целое
Таблица 10
Определение типов таблицы "Зарплата мастера"
Атрибут Расшифровка Тип
Id_zp_mst Идентификационный номер Автосчетчик
Kol_sak Количество заказов Целое
Nachisleno Начислено Вещественное id_master ID мастера Длинное целое
Таблица 11
Определение типов таблицы "Услуги"
Атрибут Расшифровка Тип id_uslugi Идентификационный номер Автосчетчик usluga Название услуги Строка cena Цена Деньги
Таблица 12
Определение типов таблицы "Мастер-услуга"
Атрибут Расшифровка Тип id_uslugi ID услуги Длинное целое id_master ID мастера Длинное целое
Таблица 13
Определение типов таблицы "Сотрудник"
АТРИБУТРАСШИФРОВКАТИП id_sotrudnik Идентификационный номер Автосчетчик
Fam Фамилия Строка
Name Имя Строка
Otch Отчество Строка dolzhnost Должность Строка seria_pasp Серия паспорта Целое nomer_pasp Номер паспорта Длинное целое data_post_na_rab Дата поступления на Дата oklad Оклад Деньги
Таблица 14
Определение типов таблицы "Заказ-сотрудник"
Атрибут Расшифровка Тип id_sakas ID заказа Длинное целое id_klient ID клиента Длинное целое id_sotrudnik ID сотрудника Длинное целое
Таблица 15
Определение общих типов таблицы "Отчет"
АТРИБУТРАСШИФРОВКАТИП id_otch Идентификационный номер Автосчетчик id_zp_mst ID зарплаты мастера Длинное целое id_sotrudnik ID сотрудника Длинное целое id_sak_sklada ID заказа склада Длинное целое id_detal ID детали Длинное целое
Mes Месяц Строка god Год Строка
Таким образом, определены все таблицы для разработки базы данных с общими типами. Для определения конкретных типов необходимо выбрать программное обеспечение для реализации информационной системы.
2.3 Анализ и выбор ПО для разработки СУБД
Для выбора программного обеспечения для реализации оценим несколько самых распространенных программных продуктов по следующим критериям: распространенность;
финансовая доступность;
поддержка защиты данных;
Каждый критерий оценивается по трехбалльной системе и может принимать значения "1", "2", "3". Где оценка "1" соответствует наихудшему удовлетворению критерия, а оценка "3" - наилучшему.
Таблица 16
Оценка программного обеспечения для реализации
Программное обеспечение Критерии Paradox 7 Oracle INFORMIX INTRBASE MSACCESS MSSQL распространенность 3 3 2 2 3 3 финансовая доступность 3 1 3 2 3 2 поддержка защиты данных 3 3 1 2 2 2
ИТОГОВЫЙ БАЛЛ: 9 7 6 6 8 7
Следуя из оценки программного обеспечения, для разработки данной информационной системы будет взята за основу СУБД Paradox 7.
Информационную систему можно реализовать в различных средах программирования. Например, таких как: SQL, Java, JAVASCRIPT, XML, Builder C , Visual Basic, Delphi. Для разработки системы нужного уровня наиболее часто применяются Builder C , Visual Basic, Delphi, поэтому производить оценку будем именно по ним.
Для выбора среды программирования для реализации оценим каждый программный продукт по следующим критериям: генерация кода. Возможность генерации кодов на одном или нескольких языках на основе проектных спецификаций. Типы генерируемого кода могут включать обычный программный код, схему базы данных, запросы, экраны/меню;
компиляция кода;
отладка. Типичные функции отладки - трассировка программ, выделение узких мест и наиболее часто используемых фрагментов кода и т.д.;
генерация экранных форм;
механизм доступа к определенной БД: надежность
Все перечисленные выше критерии имеют одинаковую значимость, поэтому оцениваются по одной шкале оценок.
Критерии могут иметь оценки 1,2,3.
Оценка "1" означает, что ПО минимально удовлетворяет данному критерию или не удовлетворяет вообще.
Оценка "2" показывают среднюю степень выполнения условий критерия.
Оценка "3" означает, что критерий в данном ПО выполняется полностью.
Оценка программного обеспечения представлена в таблице 17.
Таблица 17
Оценка средств программирования
Программные продукты Критерии Builder C Visual Basic Delphi генерация кода 2 3 компиляция кода 3 3 отладка 3 2 генерация экранных форм 3 3 механизм доступа к определенной БД 3 2 надежность 3 2
ИТОГОВЫЙ БАЛЛ: 17 16
Из оценки по поставленным критериям видно, что для разработки данной БД наиболее подходящим является среда программирования Builder С .
2.4 Функциональная схема приложения
Для внесения ясности в функциональную схему приложения распишем некоторые основные функции более подробно.
Функция поиска клиента по базе данных: Поиск будет осуществляться по ID клиента, если он его помнит, или по фамилии и номеру автомобиля. Если поиск производиться по ID клиента, то в таблице "Клиент" перебираются все ID и на экран выводится фамилия, имя, отчество и номер автомобиля клиента, чтобы исключить случайные ошибки. Если же поиск производиться по фамилии и номеру автомобиля, то в таблице "Клиент" перебираются фамилии и номера машин так, чтобы одновременно совпадали оба параметра, так как клиенты могут бить с одинаковыми фамилиями. Если клиент не найден, на экран должно выйти сообщение. Если клиент найден, то есть он уже когда-либо оформлял заказы, то информация о его заказах должна вывестись на экран.
Функция оформления нового заказа: Если клиент найден в базе данных, то при оформлении заказа известная информация автоматически заносится в форму. Другая нужная информация: детали, услуги, данные о исполняющих мастерах - вводится путем выбора из списка, чтобы избежать различных опечаток. При выборе какой-либо детали заполняется таблица "Деталь-заказ", в которой прописываются данные ID заказа и ID детали. При этом из таблицы "Деталь" в записи соответствующей детали меняется количество. Это необходимо для учета деталей на складе.
Если же поиск не дал положительных результатов, то фамилия, имя, отчество и номер автомобиля клиента вводится вручную. Остальная информация вводится аналогично из списка. При добавлении заказа в таблицы сначала заполняется таблица "Клиент", новому клиенту присваивается ID, которое система высчитывает автоматически, так как тип данного поля - автосчетчик. Последующая информация вводится в таблицы аналогично первому случаю поиска.
Функция авоподсчета стоимости заказа: При сохранении заказа система считывает информацию по каждой услуге и детали через их ID. При подсчете стоимости деталей учитывается также число каждого типа деталей, так как замене могут подлежать сразу несколько одинаковых деталей. Далее все эти стоимости складываются, и результат выводиться на экран и сохраняется также в заказ. Все дополнительные расходы и оплата за работу, входят в стоимость деталей и услуг, поэтому не требуют дополнительных расчетов.
Автоудаление заказов, не требующих дальнейшего хранения: В каждом заказе отмечается дата закрытия заказа. По закону необходимо хранить все отчеты 3 года. Для того чтобы не занимать лишние ресурсы памяти, заказы, дата закрытия которых раньше, чем 3 года назад, удаляются. То есть система периодически сверяет текущую дату с датой закрытия заказа, и, если разность дат превышает 3 года, заказ удаляется.
2.5 Описание особенностей интерфейса. Разработка отчетов
На основе основных функций распишем необходимые отчеты.
Для того чтобы заказчик мог забрать свой заказ, необходимо предоставить ему некоторый отчет, который должен содержать всю информацию по заказу - данные, вводимые при заполнении заказа (см. выше).
Для контроля внутренней работы фирмы необходимо проверять все финансовые затраты и доходы. Для этого также используются отчеты, содержащие месяц и год, за который сделан отчет, информацию обо всех сотрудниках и их зарплатах, затраты на приобретение деталей в данный период времени и другие затраты. Также отчет должен включать полный доход за месяц.
Для каждого сотрудника соответственно должны также выполняться отчеты, содержащие информацию о выполненной работе и ее стоимости, общее начисление за месяц.
2.6 Математические методы в прогнозировании
2.6.1 Формулировка задачи на прогнозирование
Для планирования развития организации часто используют прогнозирование доходов. Поэтому за прогнозируемую величину возьмем рост доходов (чистых). На величину чистой прибыли влияет количество и стоимость заказов, количество всех расходов. Таким образом, необходимо найти как будут изменяться доходы в ближайшем будущем, основываясь на результатах прошедшего периода.
Поиск и анализ математических методов для прогнозирования.
По оценкам ученых, насчитывается свыше 150 различных методов прогнозирования; на практике же в качестве основных используется лишь 15-20. Также существует множество классификаций этих методов, основанных на различных построениях методов, сложности, точности и других параметров. К точным методам относятся, например, экстраполяция, моделирование, метод исторической аналогии, написание сценариев, анализ корреляций и другие.
2.6.2 Экстрополяционные методы прогнозирования
Методы экстраполяции тенденций являются, пожалуй, самыми распространенными и наиболее разработанными среди всей совокупности методов прогнозирования. Использование экстраполяции в прогнозировании имеет в своей основе предположение о том, что рассматриваемый процесс изменения переменной представляет собой сочетание двух составляющих-регулярной и случайной.
Считается, что регулярная составляющая f (a, х) представляет собой гладкую функцию от аргумента (в большинстве случаев - времени), описываемую конечномерным вектором параметров а, которые сохраняют свои значения на периоде упреждения прогноза. Эта составляющая называется также трендом, уровнем, детерминированной основой процесса, тенденцией. Под всеми этими терминами лежит интуитивное представление о какой-то очищенной от помех сущности анализируемого процесса. Интуитивное, потому что для большинства экономических, технических, природных процессов нельзя однозначно отделить тренд от случайной составляющей. Все зависит от того, какую цель преследует это разделение и с какой точностью его осуществлять.
Случайная составляющая n (х) обычно считается некоррелированным случайным процессом с нулевым математическим ожиданием. Ее оценки необходимы для дальнейшего определения точностных характеристик прогноза.
2.6.3 Метод Исторической Аналогии
Метод прогнозирования, основанный на установлении и использовании аналогии объекта прогнозирования с одинаковым по природе объектом, опережающим первый в своем развитии.
2.6.4 Экспертные методы
Методы экспертных оценок в прогнозировании и перспективном планировании научно-технического прогресса применяются в следующих случаях: а) в условиях отсутствия достаточно представительной и достоверной статистики характеристики объекта (например, лазеры, голографические запоминающие устройства, рациональное использование водных ресурсов на предприятиях);
б) в условиях большой неопределенности среды функционирования объекта (например, прогнозов человеко-машинной системы в космосе или учет взаимовлияния областей науки и техники);
в) при средне - и долгосрочном прогнозировании объектов новых отраслей промышленности, подверженных сильному влиянию новых открытий в фундаментальных науках (например, микробиологическая промышленность, квантовая электроника, атомное машиностроение);
г) в условиях дефицита времени или экстремальных ситуациях.
Экспертная оценка необходима, когда нет надлежащей теоретической основы развития объекта. Степень достоверности экспертизы устанавливается по абсолютной частоте, с которой оценка эксперта в конечном итоге подтвер